Re: [hybi] New port and Tunneling?

[Willy Tarreau <[e-mail]>]

Hi Greg,

On Mon, Aug 16, 2010 at 05:43:13PM +1000, Greg Wilkins wrote:
(...)
> 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.

In fact, not from my observations for a simple reason : the intermediaries
I've seen failing on 101 always abruptly closed the connection. But that
does not preclude that the connection will never be usable, just that in
some (most?) situations, the connection will have to be reopened.

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

The connection header (I mean "connection: close") has been used for at
least 10 years and is really mandatory to get HTTP messaging right. The
Upgrade header has only been referred to in the RFC2817 and was not as
much used. I *believe* it is also used by some remote desktop protocols
that start as HTTP and switch to their own protocol, though I can't
verify it.

And most of the components I've seen don't support Upgrade yet while
they've been supporting "connection: close" for ages.

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

That's a very smart idea. Simple and efficient. Can be used as an explicit
ACK when needed and does not require more round trips at all !

Regards,
Willy