Difference between revisions of "Reverse HTTP"
Line 59: | Line 59: | ||
<{} | <{} | ||
</pre> | </pre> | ||
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. |
Revision as of 12:42, 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.
>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.