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

[Jamie Lokier <[e-mail]>]

Greg Wilkins wrote:
> On 17 July 2010 12:37, Jamie Lokier <[e-mail]> wrote:
> > hybi issue tracker wrote:
> > 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.
> 
> >From those same discussion, I concluded that the intent of this
> "feature" was to fast fail in the presence of any kind of HTTP proxy.
> Given that this "feature" is now resulting in a hang if there is such
> a proxy, then I think it is still a bug whatever way you look at it.

I agree with something implied here: fast failing is more desirable
than slow failing, where it's realistically feasible to trigger fast
failing without causing problems.  It can't be guaranteed, and there's
no point overcomplicating it, but it's useful to try.

> More importantly, the best way to test if a connection will support
> websocket packets, is to just send websocket packets.   Sending 8/16
> random bytes immediately after the HTTP handshake may succeed for a
> huge variety of implementation reasons that still do not mean that
> websocket packets will succeed.   More importantly, to detect the
> non-success of sending of the 8/16 random bytes will still involve the
> same timeout handling that would be required to check the transmission
> of websocket packets.

The argument against just sending WebSocket packets is that some
WebSocket packets may be valid HTTP and therefore more likely to be
misinterpreted or be used as another attack vector, or simply fail to
fail fast.

That's not possible with the current WebSocket frame types, but it
could happen with frame types from the currently reserved range.

That's also an argument against making the bytes uniformly random;
instead they should also be constrained to avoid looking like HTTP.

-- Jamie