Difference between revisions of "Reverse HTTP"

From Second Life Wiki
Jump to navigation Jump to search
Line 1: Line 1:
Reverse HTTP is an experimental protocol which takes advantage of the HTTP/1.1 Upgrade: header to turn one HTTP socket around. When a client makes a request to a server with the Upgrade: PTTH/1.0 header, the server may respond with an Upgrade: PTTH/1.0 header, after which point the server starts using the socket as a client, and the client starts using the socket as a server. There is also a COMET-style protocol which will work with HTTP/1.0 or 1.1 clients that do not know how to perform this upgrade.
Reverse HTTP is an experimental protocol which takes advantage of the HTTP/1.1 Upgrade: header to turn one HTTP socket around. When a client makes a request to a server with the Upgrade: PTTH/1.0 header, the server may respond with an Upgrade: PTTH/1.0 header, after which point the server starts using the socket as a client, and the client starts using the socket as a server. There is also a COMET-style protocol which will work with HTTP/1.0 or 1.1 clients that do not know how to perform this upgrade.


Below is an example transcript using Reverse HTTP. Lines beginning with > are traffic from the client to the server. Lines beginning with < are traffic from the server to client.
Below is an example transcript using Reverse HTTP. Lines beginning with > are traffic from the client to the server. Lines beginning with < are traffic from the server to client. The transcript was created by sniffing the traffic from running this script [[http://soundfarmer.com/paste/B4B75B7A-2E16-4CB1-B0BC-98ADAD2B9214.py]].


<pre>
<pre>

Revision as of 12:51, 13 May 2008

Reverse HTTP is an experimental protocol which takes advantage of the HTTP/1.1 Upgrade: header to turn one HTTP socket around. When a client makes a request to a server with the Upgrade: PTTH/1.0 header, the server may respond with an Upgrade: PTTH/1.0 header, after which point the server starts using the socket as a client, and the client starts using the socket as a server. There is also a COMET-style protocol which will work with HTTP/1.0 or 1.1 clients that do not know how to perform this upgrade.

Below is an example transcript using Reverse HTTP. Lines beginning with > are traffic from the client to the server. Lines beginning with < are traffic from the server to client. The transcript was created by sniffing the traffic from running this script [[1]].

>POST / HTTP/1.1
>Host: localhost:9999
>Accept-Encoding: identity
>Upgrade: PTTH/1.0
>
<HTTP/1.1 101 Switching Protocols
<Content-type: text/plain
<Upgrade: PTTH/1.0
<Date: Tue, 13 May 2008 20:14:45 GMT
<Content-Length: 0
<
<GET / HTTP/1.1
<Host: 127.0.0.1:65331
<Accept-Encoding: identity
<accept: text/plain;q=1,*/*;q=0
<
>HTTP/1.1 200 OK
>Content-type: text/plain
>Date: Tue, 13 May 2008 20:14:45 GMT
>Content-Length: 15
>
>rdlrow ,olleH
>

COMET Fallback

If the client or server is incapable of upgrading from HTTP, a COMET-style protocol can be used instead. The server can maintain an event queue and require that the client repeatedly POST to the queue's resource to receive events. Below is a protocol trace using JSON as the protocol encoding.

>POST / HTTP/1.1
>Host: localhost:9999
>Accept-Encoding: identity
>Upgrade: PTTH/1.0
>
<HTTP/1.1 200 OK
<Content-type: application/json
<Date: Tue, 13 May 2008 20:14:45 GMT
<Content-Length: 210
<
<{'message-id': 'xxx', 'method': 'GET', 'request-uri': '/', 'http-version': 'PTTH/1.0', 'headers': [['Host', '127.0.0.1:65331'], ['Accept-Encoding', 'identity'], ['Accept','text/plain;q=1,*/*;q=0']], 'body': ''}
>POST / HTTP/1.1
>Host: localhost:9999
>Accept-Encoding: identity
>Content-type: application/json
>Content-length: 193
>
>{'message-id': 'xxx', 'http-version': 'PTTH/1.0', 'status': 200, 'reason': 'OK', 'headers': [['Content-type', 'text/plain'], ['Date', 'Tue, 13 May 2008 20:14:45 GMT']], 'body': 'rdlrow ,olleH'}
<HTTP/1.1 200 OK
<Content-type: application/json
<Date: Tue, 13 May 2008 20:14:45 GMT
<Content-Length: 2
<
<{}

Another idea is to use text/plain encoding instead of JSON, and just have the actual text of the HTTP request in the response, and the text of the response in the next request.