Reverse HTTP == Remote CGI
This page is a mirrored copy of an article originally posted on the (now sadly defunct) LShift blog; see the archive index here.
Sun, 8 March 2009
I’ve been working recently on Reverse HTTP, an approach to making HTTP easier to use as the distributed object system that it is. My work is similar to the work of Lentczner and Preston, but is independently invented and technically a bit different: one, I’m using plain vanilla HTTP as a transport, and two, I’m focussing a little more on the enrollment, registration, queueing and management aspects of the system. My draft spec is here (though as I’m still polishing, please excuse its roughness), and you can play with some demos or download and play with an implementation of the spec.
Comments welcome!
Comments
On 10 March, 2009 at 9:00 am, wrote:
On 30 June, 2009 at 1:15 am, wrote:
There’s already a technology called “Reverse HTTP”, and its used by Linden Labs for Second Life. The draft is registered with the IEFT[1]. It describes a protocol that reverses the HTTP session, such that the browser serves content, and the server requests content.
Reading your spec, I’m not immediately struck with knowing what purpose it serves, what its use case is. It seems like a way for different HTTP services to register themselves with a central service, kind of a DDNS (clients register themselves) of HTTP? I like the idea of a protocol for routing, but I think there needs to be more emphasis that thats what this spec is: a protocol for manipulating a HTTP servers routing table. I myself am using Spring to manage these mappings on a more static basis: its an interesting problem definitely, and I can see the need for a protocol for it.
I’m not sure how routing table manipulation is tantamount to reverse http. Remote cgi seems clearer, although still obfuscating what I see as, “routing/proxy configurition protocol”. Add in the confusion of being the second person to claim the spec name “Reverse HTTP,” long after Linden Lab’s sent their draft to the IETF, and I’d suggest perhaps a renaming may be benficial.
On 30 June, 2009 at 12:57 pm, wrote:
Yes, I’m aware of Lentczner & Preston’s work — I even linked to it and discussed its similarities and differences to my work in the post you’re commenting on :-)
You can see the http://www.reversehttp.net spec as two pieces:
-
(1) a means of getting HTTP requests from the “server” to the “client”, and responses back in the other direction, and
-
(2) a means of claiming some URL space to use with the first piece.
It’s piece 1 — the transport — that is effectively the same idea as Lentczner & Preston’s IETF draft, with a different expression. Piece 2 is new: it’s a means for assigning names to clients, making HTTP symmetrical in a way it hasn’t been to date. It’s similar in some ways to the things Opera’s Unite offers.
Regarding renaming, you may be right — a number of people I’ve spoken to about it have been confused by the term “reverse HTTP”. The idea has been independently invented and named at least three different times though, well before the IETF draft, and the name “reverse HTTP” has seemed applicable in the eyes of at least two of the teams concerned, so perhaps it’s not so bad.
On 4 August, 2009 at 5:48 pm, wrote:
Hi,
Reverse HTTP sounds very interesting so I downloaded
the Java implementation but the examples didn’t to seem to work. I tried TestNormalHttpService with TestReverseHttpService.
So how to get things working?
And is TestNormalHttpService the server and TestReverseHttpService the client, atleast before they switch roles?
Thanks,
Evert
On 5 August, 2009 at 12:17 am, wrote:
Evert: The Java code is for building Applications only. It contains a simple HTTP server library that can run either directly, using a normal server socket (TestNormalHttpService) or indirectly, using reversehttp (TestReverseHttpService). In the latter case, it will need to run against some reversehttp gateway server. There is, as far as I know, only the one implementation of a gateway server so far, and it’s written in Erlang. Please feel free to use the demo gateway, with Gateway Service URL at http://www.reversehttp.net/reversehttp, though!
On 5 August, 2009 at 12:18 am, wrote:
(I mean “Application” and “Gateway Service” in the sense of section 3 of the specification)
There’s an interesting discussion about this stuff going on at Hacker News: http://news.ycombinator.com/item?id=508238.