Re: [hybi] Redesigning the Web Socket handshake

[Maciej Stachowiak <mjs at apple.com>]

On Feb 3, 2010, at 8:33 AM, Jamie Lokier wrote:

> Nice!  But that's not really what I meant.
> 
> What I meant is two things, I suppose.  One protocol, one client API:
> 
> Protocol: Establishing a connection, and then each proxy in the chain
> either opts in to making it a WebSocket (or similar in style)
> resulting in single connection with bidirectional messaging, or if
> there are any proxies detected which won't participate, there will be
> HTTP long-polling - at least for the hops on either side of that proxy
> (perhaps not the other hops).
> 
> I *think* what you described is: Use WebSocket if the whole path
> supports it, otherwise long-polling for the whole path.
> 
> The difference from what that is the intentional proxy-friendliness
> and friendliness to all other deployed HTTP infrastructure.  It'll
> pass through everything, including the internals of xrandomhttpd <->
> CGI, etc. and upgrade to WebSocket opportunistically on those hops
> where it can, while working transparently to the user where it can't.
> 
> For the API, you've probably understood that it'd be nice if the
> WebSocket API had a fallback to HTTP long-polling implementation,
> Of course that can be written in Javascript today.

That would be cool if it worked. But I'm not sure how you would detect that all your intermediaries understand WebSocket. Our best idea so far was hop-by-hop headers. But as someone else mentioned, there are intermediaries out there that just pass along hop-by-hop headers, but won't deal with arbitrary bidirectional non-HTTP traffic. So there doesn't seem to be a reliable mechanism for this.

Regards,
Maciej