What on earth is ReverseHTTP and why would it be useful?

reversehttp.net offers little immediate insight into what reversehttp truly is and how t开发者_Go百科his can be best utilized, it makes it seem that this tool is too difficult to realistically implement. In what sorts of environments might this be the ideal real-time web data situation and when would this not work, What browsers support this method, and What is it exactly?

• What makes reversehttp unique from other PUSH implementations?

Thank you to anyone who can help and has first of all heard of this, and knows what it is.

Reverse HTTP is a way for the client to keep an open connection to a web server so that the web server can push updates to the client (rather than the client continually having to ask for updates).

Take your classic Twitter client for example.

Currently, the client asks Twitter periodically if you have any updates. If not, it's a wasted request.

With technology like Reverse HTTP, once you establish the connection to Twitter...Twitter would be able to send you the updates when they happen saving both you and Twitter some bandwidth, overhead, and a little effort.

Reverse HTTP works by running a Web Server inside the browser that the server communicates with.

There are similar technologies that accomplish the same goal in a safer, more secure way. Microsoft.NET implements these kinds of services as Duplex Binding services in WCF by keeping the connection between the client and server open once it is made (instead of running a seperate server on the client). There's also a technology called Comet which allows the same thing.

I've looked at the source of the Reverse HTTP you linked to. The implementation consists of two parts:

1. The HTTP relay. This one is hosted on the website reversehttp.net. It simply waits for requests to a certain URL (the one that is generated) and forwards it to a channel (see 2). It then waits on another channel (see 2), and forwards that to the requester.

2. The HTTP JavaScript server. The "client server" polls the "server server" for any incoming requests using Ajax. Then, when you've requested the url on the "server server", and it's forwarded to a channel, it will be send to the "client server". The client server will then parse the original HTTP request from the request at step 1, create an answer (the HTTP reply). This answer will be send back to the "server server" which ends up in the channel which sends the actual reply back to the requester.

It's not at all hosting a real HTTP server on the client. This requires an open port 80, which most people don't have. If you're behind a NAT or a Firewall, it will be blocked any way, if configured well.

I guess using long-polling or Comet is a better idea than using this. The overhead of parsing HTTP headers on the client is quite cumbersome.

The specification describes a way of relaying HTTP requests. This will be done by setting the Content-Type header of any request to the "server server" to message/http. I think there are better solutions for proxying or relaying HTTP requests anyway, simply by changing the Host field of the to-be-relayed-to, adding a special field that contains some reference to the original sender and path it traversed, and sending the modified HTTP request to the next server. Then the receiver will send the request simply back, and the receiver looks for the special field, pops of it's origin, and passes the reply further in the chain.

Just browsing the page: My reading is that instead of, say, a web browser polling for updates and pulling any new data, the web server instead pushes new data on the client when it becomes available.

For applications that require quick response to any new data, this would eliminate a lot of the traffic caused by repeated polling.

From looking at some of the demos (e.g. this one) it looks like it's built on top of a standard comet-style interface. The implementation just presents itself as a complete HTTP server to the client.

So in your javascript, it "looks like" you're hosting a web server that responds to requests for "http://reversehttp.net/demo12345/" but in reality, requests are being tunneled from the "real" web server via comet requests to the javascript client running in the browser and back again.

When described like that, it seems rather inefficient, but when you consider that in most situations, the client and server would both be running on the same computer (so it's only ever two computers talking to each other) then the inefficiency mostly disappears.