ReverseHttp

http://www.reversehttp.net/

by apgwoz • 17 years ago

26 36 17 years ago

This is a different propopsal than the IETF draft by Donovon Preston, which is knows as "Reverse HTTP".

This is apparently "ReverseHTTP" and the specification looks about twenty times longer, needlessly. I'd love to hear any good reasons why I should use this "ReverseHTTP" instead of long-polling or Reverse HTTP... the IETF draft

tonyg8• 17 years ago

It's very similar to Lentzcner & Preston's I-D, yes. We both seem to have independently invented the same general idea and chosen the same obvious name. The differences are the use of a ReSTful protocol, and more elaboration of the registration/name-management aspects. And of course that I haven't submitted it as an I-D :-)

My current draft is far too long, I agree; it describes not only the use of HTTP to retrieve requests (which is equivalent to Donovan Preston's idea), but also the interactions and headers needed to manage the tunnelled service. That latter is something that Lentzcner & Preston haven't addressed yet, I think.

samueladam• 17 years ago

The demo speaks for itself.

http://www.reversehttp.net/demos/demo.html

DLWormwood2• 17 years ago

Case breaks things; entering a sub-domain name with uppercase letters causes the local server to fail. DNS names are supposed to be case-insensitive.

http://www.rfc-archive.org/getrfc.php?rfc=4343

apgwoz3• 17 years ago

is that the fault of DNS or the actual server sitting behind it, expecting the host header?

axod2• 17 years ago

In safari, the loading spinner never stops. Not a good thing.

I don't really see what this is trying to solve either.

apgwoz3• 17 years ago

I believe Comet works around this by using iframes, though I could be wrong. Either way, ReverseHTTP is another way to not have to poll for resources, which might be useful for instance in real time chat.

axod2• 17 years ago

It's all in fuzzy definitions, but this is using 'comet'.

Comet is generally used to refer to any method that can emulate a raw socket - iframes, xhr, inserting script tags, etc etc

All this is doing is proxying http from the server, to the browser and back. It's an interesting thing to try, but I can't see any real life use for it.

tonyg8• 17 years ago

Thanks for the pointer re: Safari. I'll fix that.

What this is doing is twofold: letting HTTP push be used consistently, with long-polling pushed out to the edges of the network, where it belongs; and making it less of a burden to spin up and shut down HTTP-based services.

The registration and management aspect -- enrollment, in short -- is to HTTP as DHCP is to IP, if you like. It lets you avoid the equivalent of manually assigning IP numbers.

tjogin4• 17 years ago

Neat, almost a bit magical. But what kind of common web development problems does this solve?

I'm sure there are a lot of contrived examples, but are there any good ones? Facebook and Twitter.

Ok, but are there any good and common ones?

apgwoz3• 17 years ago

Maybe there are no "common" uses just yet because we do not have an easily implemented way to do it. When Ajax first " came out", many said the same things. "great but what do we use it for." now, can you imagine the present day web without it?

tptacek2• 17 years ago

I remember almost exactly the opposite about AJAX (when the paper came out, not when the XmlHttpRequest object was introduced) --- people went ape about what they could use it for. AJAX style genuinely made new things possible. This (supposedly) just makes them cleaner.

tjogin4• 17 years ago

You have a point. But I have to say that I didn't need any imagination to think of ways to use Ajax to enhance parts of my web app interfaces.

The only reason I hadn't use xmlhttprequests extensively before it became popular (and renamed Ajax) was because it was too much work, too error prone. The popularization of Ajax lead to solid frameworks and libraries, which fixed that.

andrewbadera• 17 years ago

Messaging/queuing/publishing-subscribing is required in an incredible number of complex applications, especially at the enterprise level. Consider, for instance, trading floor and backend systems.

tjogin4• 17 years ago

True, but they rarely use web interfaces, do they?

extension4• 17 years ago

There are two protocols described here. One is an extension to HTTP which allows the client and server to swap roles while still using the same connection. This would allow a server to "push" events to a client asynchronously. This will never work in a browser.

The other protocol tunnels an HTTP connection over another HTTP connection in the opposite direction. Tunneling asynchronous messages over HTTP is an old technique which can be implemented in a browser.

Neither protocol enables any kind of novel functionality. They merely add another layer of HTTP cruft.

tonyg8• 17 years ago

Well, the intent is to design a systematic way of setting up a relay for HTTP requests from a public internet through a gateway to an application that otherwise wouldn't be publicly addressable. Without a protocol like the one I've drafted, setting up HTTP servers or CGI scripts stays ad-hoc, requiring local access to the gateway server and DNS and firewall configuration.

extension4• 17 years ago

The problem could be solved much more generally with a protocol to request socket level forwarding of arbitrary network services. This could be used transparently to create a gateway for HTTP or any other protocol. Some existing protocols come close to doing this (e.g. SSH) but I don't know of any that handle public namespace allocation.

For the case of "works in a browser today" aka Comet, it is again better to solve the more general problem of bidirectional tunneling over HTTP (e.g. http://xmpp.org/extensions/xep-0124.html), through which you could make any sort of connection, including a reversed HTTP connection or the gateway request protocol above.

Imposing an extra HTTP layer and/or building on top of HTTP (in the first case) needlessly complicates and significantly restricts both of these protocols without deriving significant value from existing standards or infrastructure.

int2e• 17 years ago

How about just using hanging gets?

DomesticMouse3• 17 years ago

Maybe it makes some sense in server apis?

I don't know. I'm sold on using long polls in conjunction with actors...

patrickdlogan• 17 years ago

Not sure I buy the premise "Polling for updates is bad." Certainly reverse http and/or web hooks do not cover, for example, all the same cases as http/atom/atompub. I'd like to see people's guidance on when to consider one or the other.

tonyg8• 17 years ago

Perhaps more accurately, polling for updates in an event-based network is suboptimal -- especially since we have all this lovely packet-switching machinery available for use! -- but it's not completely wrong. Polling an RSS feed is equivalent to (a shitty form of) queue replication, and (slightly less closely) to TCP retransmissions, where event notification is equivalent to message delivery and to TCP segment transfer. The two approaches are in a sense dual. You can construct a message-streaming system from a state-replication system, and you can construct a state-replication system from a message-streaming system. Of course this still doesn't address when one or the other should be used: for that you have to get into the different scenarios for message replication. RSS/Atom etc are great when latency doesn't matter and you are multicasting, or when recipients desire (relative) anonymity. The cacheability of the polling approach can also be valuable.

Neither pull nor push solves the problem that SUP tries to address. For that, a layer on top is required -- essentially an embedded message broker with configurable private/shared queues and bindings. One very promising approach, once the transport is sorted out (which is what ReverseHttp is trying for), is to transplant the AMQP model (objects and operations) into the new setting.

ReverseHttp

Related Stories