Reverse HTTP

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. In this case, the message-id would be relayed in a header instead of in the body. Perhaps the message id should always be relayed in a header and never in the body?