Re: [hybi] New port and Tunneling?

[Willy Tarreau <[e-mail]>]

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.

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.

> 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.

> 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.

Regards,
Willy