Re: [hybi] Redesigning the Web Socket handshake

[Jamie Lokier <jamie at shareable.org>]

Greg Wilkins wrote:
> Jamie Lokier wrote:
> 
> > An interesting idea I've looked at, which would be tricky but _really_
> > improve widespread support (and compatibility), would be to send
> > something which looks like a valid HTTP long-polling request, and
> > allow the server and any proxies to proactively signal that they'll
> > convert it to the more efficient WebSocket - when they will.  When
> > they won't, communication continues over HTTP long-polling, carrying
> > the same messages and subprotocols over that.  I guarantee if that
> > could be pulled off, everyone would start using WebSocket asap ;-)
> 
> Cometd-2 (in alpha state) is more or less doing this already.
> 
> It should be in beta release shortly and then any cometd client
> will be able to use websockets if the browser has it and the
> server handshake says that the server supports it.  Otherwise
> it is long polling business as usual.

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.

-- Jamie