Re: [hybi] New port and Tunneling?

[Greg Wilkins <[e-mail]>]

Willy,

I agree with your analysis of the problem, but I remain hopeful that a
better solution than Connection:close may be found, as this prevents
the HTTP connection being used after a failed upgrade (by a BOSH/comet
fallback).

Having the server send a ws message after the handshake should be a
good way to quickly detect this problem.  Adding a simple checksum to
the framing would also quickly detect most varieties of intermediaries
not acting as pure tunnels.

cheers





On 16 August 2010 15:18, Willy Tarreau <[e-mail]> wrote:
> Hi Greg,
>
> On Mon, Aug 16, 2010 at 01:09:22PM +1000, Greg Wilkins wrote:
>> Shelby,
>>
>>
>> The concerns I've mostly seen discussed is for an intermediary to pass
>> the handshakes, but then not forward arbitrary data.
>>
>> However,I guess it is possible for a really stupid proxy to inject
>> "HTTP headers" or similar into a websocket stream and corrupt data,
>> specially if the data looked like a HTTP message.    Perhaps that is
>> an argument for a simple checksum in the framing mechanism (previously
>> suggested and rejected because we are not trying to fix problems with
>> TCP/IP - but this is a different use-case).
>
> What could very well happen in fact is that an intermediary does not
> know that "101" requires all the chain to switch to tunnel mode, and
> that it then considers the first data from the client as a second
> request. It will send return "HTTP/1.1 400 Bad Request" in the response,
> which does not look like a WS frame at all. That's why I was advocating
> (and Jamie too) for the use of "Connection: close" in the request
> headers. At least the intermediaries will know that they must close
> after the first request is done. That will also improve fast fail on
> incompatible components, because we won't have to wait for sending data.
>
> But I'm not worried for the rest. Having random headers inserted in the
> 101 response is not a problem at all. And I don't see why any data could
> get corrupted at all. At worst we could imagine that some IDS/IPS will
> sometimes believe they see a known bad signature and reset the
> connection as they sometimes do on HTTPS traffic, but there are many
> other reasons for connection that we have to deal with.
>
> Regards,
> Willy
>
>