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

[Willy Tarreau <[e-mail]>]

On Mon, Aug 30, 2010 at 10:24:09PM -0000, 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:     
> -------------------------------------------+--------------------------------
> 
> Comment(by ifette@???):
> 
>  I definitely want to figure out how to fix this issue. That said, even
>  reading the linked messages, I don't see any solutions readily available.
>  Putting the 8 bytes in a header seems to imply that we're not actually
>  certain that the proxy is capable of forwarding the data correctly (the
>  data that would be sent on the first message). This seems undesirable.
>  Adding a 2nd RTT is also desirable.
> 
>  From the referenced message http://www.ietf.org/mail-
>  archive/web/hybi/current/msg03238.html
> 
>  "Note that this data is used for three things :
>    - detection of cross-protocol communication
>    - ensure that no cache will return a cached content
>    - ensure that intermediaries correctly forward data after the 101
> 
>  "The first point and second points are not changed with a header. The
>  third point changes slightly. With the key in the data, it was able
>  to detect some of the proxies which would reset the connection during
>  the handshake. With the key3 in a header, it will only detect the
>  connection reset when trying to send data for the first time. However,
>  neither method detects intermediaries which don't forward request body
>  and remain stuck on it, so on this point there is no change."
> 
>  The status quo is also undesirable as we may hang on some proxies, which
>  also is a bad state to be in.
> 
>  My understanding of this issue is that we are still looking for a
>  solution. As such, I am not planning to address this in -01, but will make
>  a note of the issue and that it is still open.

It is possible to keep the same exchange but only state that the server must
respond the 101 as soon as it has got all the headers, then read the nonce
and respond with the hash. It's left as a choice on the client side to decide
whether it wants to send them both at once to avoid a round-trip, or one at
a time in case some authentication or anything else is required.

However I think that we should discuss this on the list once the new framing
is agreed upon : instead of having both the client and the server implement
a specific case for something barely looking like some data can flow, we can
as well send a real WS frame and expect a real one in return (eg: ping+pong).
It would then be the real opening handshake which might be used later when
the protocol evolves to other non-HTTP transport methods. HTTP would then be
just for connection establishment up to, but not including the WS handshake.

Regards,
Willy