

Reverse HTTP - vaksel
http://www.ietf.org/internet-drafts/draft-lentczner-rhttp-00.txt

======
thwarted
_The protocol token used in the Upgrade header is: PTTH/1.0_

This is a little too cutesy.

 _In this case, application layer interfaces can no longer be symmetric: If a
host needs to invoke a function on a host that cannot function as an HTTP
server, than that function cannot be easily layered on top of HTTP._

It's things like this that made me wish RFCs included a few real-life use-
cases. Because I just can't see a need for two reasons: 1) the RPC
functionality of the inaccessible host ("the client") is unknown, you actually
need to have known code running on the end that is opening the connection, and
2) it doesn't matter how bad you want to make a remote call to a machine you
can't get to if you need to wait for it to initiate the connection. If you can
put known code on a remote node, you can just have it open up a non-HTTP
connection to accept RPC calls over.

Not only does this break stock proxying, but clients would have to use the
CONNECT method to enable bi-directional requests on port 80. This is normally
reserved for things like SSL, where you need end-to-end connectivity
assurance. This sounds like a way to by-pass firewalls ("if we make it work
over HTTP, it'll be able to punch through anything!"), which may be a legit
goal, but as a system, network, and security administrator, it doesn't enamor
it to me.

~~~
tptacek
It's a clean (but probably untenable) replacement for long-polling. You open
up a web application somewhere. You make lots of little connections to grab
images, post data, etc. You also make another connection to allow the server
to post back to you.

Presumably, the idea here is that you'd be able to drive the "client's server"
side of this from Javascript event handlers.

In the real world, CONNECT proxies aren't going to allow these connections
anyways (try running Meebo through a BlueCoat). Although in fairness, the
whole industry has already adopted "run-whack-ass-protocol-over-HTTP-POST" as
the accepted tunneling solution --- that ship has sailed.

~~~
moe
Yes, replacing the monster that is comet/longpolling with something sane is
indeed a worthy goal. But I also agree, this is not the solution.

For the simple reason because it won't work over standard proxy servers and I
don't see the trillions of proxy servers currently in use being updated to
support this any time soon...

------
extension
This is probably a better solution to the problem that is already implemented
in one, albeit unpopular, browser:

[http://www.whatwg.org/specs/web-apps/current-
work/multipage/...](http://www.whatwg.org/specs/web-apps/current-
work/multipage/comms.html#server-sent-events)

------
moe
What about proxy servers?

~~~
tptacek
Probably a dealbreaker.

~~~
moe
Thought so.

