Re: [hybi] #4: handshake does not work properly with HTTP reverse proxy.

[Willy Tarreau <[e-mail]>]

On Sat, Jul 17, 2010 at 03:37:49AM +0100, Jamie Lokier wrote:
> hybi issue tracker wrote:
> > #4: handshake does not work properly with HTTP reverse proxy.
> > -------------------------------------------+--------------------------------
> >  Reporter:  salvatore.loreto@???             |       Owner:     
> >      Type:  defect                         |      Status:  new
> >  Priority:  critical                       |   Milestone:     
> > Component:  thewebsocketprotocol           |     Version:     
> >  Severity:  Active WG Document             |    Keywords:     
> > -------------------------------------------+--------------------------------
> >  the  handshake in draft-ietf-hybi-thewebsocketprotocol-00 (as in draft 76)
> >  does not work properly in presence of HTTP reverse proxy.
> > 
> >  The 8-bytes nonce from the client is not advertised as a content-length,
> >  so it is not forwarded by the reverse proxy as it is either part of a next
> >  request or pending data for when the handshake completes. Unfortunately,
> >  the server wants those bytes to complete the handshake, so we have a dirty
> >  deadlock not even detectable by the end user.
> > 
> >  for more information:
> >  http://www.ietf.org/mail-archive/web/hybi/current/msg02149.html
> 
> >From discussions on the hybi list several months ago, several times, I
> got the impression that failure to work through any kind of HTTP proxy
> was *intentional* in the handshake design.
> 
> I don't personally agree with that as a design goal, but if it is the
> design goal than this issue #4 isn't a bug.

If that goal really is to be supported, then the initial HTTP-like
handshake is overly complicated and expensive, and will serve no
purpose, as nobody will be able to use the protocol that way on shared
HTTP ports. Then let's go on with the framing protocol alone without the
fake initial handshake and let's have another draft later suggest how to
use WS over HTTP as a standard protocol Upgrade request.

Regards,
Willy