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

[Roberto Peon <[e-mail]>]

On Tue, Jul 6, 2010 at 9:41 PM, Willy Tarreau <[e-mail]> wrote:

> 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.
>
>
If we're worried about hundreds of thousands of connections, then we need
multiplexing of sessions over one TCP connection between the browser and the
server.
I, for one, am extremely worried about it, and am perhaps more worried that
many seem to be just shrugging it off-- even ignoring the server scalability
problems, NAT boxes do really funny and nasty things when their connection
tables overflow.


I do love that we're thinking about ways to make fail-fast happen within the
context of HTTP. This makes so much more sense to me.
-=R


> 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
>
> _______________________________________________
> hybi mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/hybi
>