Re: [hybi] New port and Tunneling?

[Greg Wilkins <[e-mail]>]

On 16 August 2010 16:03, Willy Tarreau <[e-mail]> wrote:
> On Mon, Aug 16, 2010 at 03:51:26PM +1000, Greg Wilkins wrote:
>> 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).
>
> To be honnest, I have very little hope of being able to reuse a connection
> after a handshake failure, because this failure will not come from the
> server itself (otherwise the application would not have proposed WS at all)
> but from client-side intermediaries (proxy or transparent proxies). And it's
> hard to guess the state the connection will be in.


I don't think you can assume that just because the javascript is most
likely to connect to the server that served it, that it will know that
server supports websocket or not.  Frameworks and applications may be
deployed in servers independently of the author of the javascript. So
the javascript author does not know if websockets will be supported by
that server unless they try. Conceivably the javascript could be
dynamically generated on the serverside, with websocket support, but
the server will still not know if websockets is supported by the
network infrastructure or not.

Thus it is likely that websocket handshake will be tried and if it is
not supported by the network infrastructure, then the upgrade header
will not be passed on or the server will not send a 101.  This leaves
a perfectly valid HTTP connection that could be used for BOSH/Comet.



> Now that you're talking about it, I now remember why we suggested the close
> on the server side too. Last week I told Ian I forgot the reason. It was
> precisely for that : ensure the proxy won't process the next request without
> blocking it at the request level. Basically, if the server sends a close but
> not the client, then the proxy will not try to process the second request,
> even if it does not understand the Upgrade. This will result in a faster
> fail.

I'm not following exactly.  However I find it unlikely that an
intermediary that does not correctly handle the connection header for
upgrades would correctly handle it for close.



>> Having the server send a ws message after the handshake should be a
>> good way to quickly detect this problem.
>
> In my opinion, the data at the end of the handshake should be put in a WS
> message. In fact it could be a "pong". That would probably mean less work
> for the client as all it would have to do is call the same code on the data
> block that comes after the 101.

+1


>> Adding a simple checksum to
>> the framing would also quickly detect most varieties of intermediaries
>> not acting as pure tunnels.
>
> Possibly, but if we're worried about them, then we should as well support
> acknowledgements, because when connections are cut on timeout, you never
> know what part has correctly been forwarded. But doing all this will result
> in a more complex protocol. Probably that the checksum could be added later
> as an extension in the frames if needed.

If you have ping/pong, then you effectively can have acknowledged delivery.
Send a message, send a ping, when you get the pong you know the
message has been delivered.