Re: [hybi] WebSocket -76 is incompatible with HTTP reverse proxies

[Willy Tarreau <[e-mail]>]

On Wed, Jul 07, 2010 at 12:44:32PM +1000, Micheil Smith wrote:
> Willy,
> 
> Thanks for raising this point. I'm an author of a node.js powered websocket 
> server, and this was actually a really awkward part of the websocket spec to 
> comply to when writing my server.
> 
> Without having a content-length header, the http parser in node doesn't know 
> how to handle the extra data it receives in that initial handshake. What we 
> ended up doing as a fix, was just to provide an upgradeHead as a slice of the
> buffer from where the headers ended to the end of the packet.
> 
> In short, I'd be all for having a content-length header sent to declare the body 
> as a body, or to declare it as just extra data that should be handled post upgrade.
> >From what I can tell from what Ian is telling me over irc, he'd be more inclined to 
> add in content-length: 0 as a header, then content-length: 8.
> 
> Hopefully this reply does make somewhat sense.

Content-length: 0 also makes sense but it means that the nonce will
be sent *after* the handshake, which means we'd have a second
round-trip. For some sites who deal with hundreds of thousands of
concurrent connections (and I know some), having two more packets
in a connectionn is an unneeded increase of network traffic. For
this reason, I think that the idea of the nonce in the request header
is good.

However, I think that having content-length: 0 in the *response* will
definitely help eliminating incompatible intermediates : those who
properly support 101 will forward the data regardless of the content
length because the tunnel is established. Those who don't completely
support 101 will stop at the content-length and not forward the
response. Alternatively, it might be nice to use a transfer-encoding:
chunked in the response with only an end of chunk ("0\r\n") before the
nonce. That would permit the client to check if it receives only the
"0\r\n" or if it receives the nonce too. An increased check could also
consist in setting "Connection: close" in the response in addition with
the transfer-encoding or content-length. That way, incompatible
intermediates won't remain open waiting for anything and will quickly
close the connection before the part they don't support.

Regards,
Willy