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.
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.
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...
Upvoted for the phrase run-whack-ass-protocol-over-HTTP-POST which accurately and creatively describes the current data streaming situation. (and made me laugh)
Why? Doesn't seem technically impossible. Proxy servers could just pass it through like they do SSL. In fact if it was SSL the proxy wouldn't even know it was happening.
Sure, it'd require people to upgrade, which could take years, but that's always the case with this kind of thing.
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.