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

[Jamie Lokier <[e-mail]>]

Willy Tarreau wrote:
> On Wed, Jul 21, 2010 at 11:30:10PM +0100, Jamie Lokier wrote:
> > Greg Wilkins wrote:
> > > 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.
> 
> Indeed, but even the first 8 random bytes can currently be used as a
> valid HTTP request or beginning of such, as some servers still accept
> HTTP/0.9 requests after a keep-alive request, and basically anything
> terminated with a line feed may constitude an HTTP/0.9 request.

According to RFC1945, a HTTP/0.9 request begins with "GET ".

> So in fact, relying on the server's 101 response to the Upgrade request
> is the most reliable thing to do, as it translates the server's intent
> to switch and to respect the negociated protocol.
> 
> Someone suggested that regularly sending keep-alives in the connection
> would be nice. I second this, especially with long-lived connections
> that will regularly get dropped on firewalls after too long idleness.
> This would also make it possible to ensure that the connection is OK.

Many people have suggested it.
I see three basic purposes for keepalives:

   - To tell the application at one end that it is up to date with
     state from the other end, with a certain amount of slack (the
     keepalive interval).  For example, a site intending to show live
     auction prices might display "information may be out of date" if
     it hasn't had a confirmation in the last 20 seconds.

   - To keep the connection open with numerous types of proxy, router,
     firewall etc.

   - To tell the server not to close the connection.  Servers must
     close connections after a timeout to avoid running out of resources.

Each of these has different timing requirements.

With WebSocket it's possible for an application to perform all the
necessary keepalives.  Strictly speaking, there is no need for them in
WebSocket itself.  However there are potential benefits to generic
assistance.  Applications might not make efficient choices for the
network context; it will be impossible for aggregators to combine
keepalives to reduce traffic because they cannot interfere with
unlabelled application messages, and some applications might (annoying
to some users) choose intervals which are too large for some networks,
or too small for others, and which drain power excessively and continuously.

That said, those are difficult to solve at any level, and it's not
immediately clear that WebSocket implementations would do a
particularly good job either.

-- Jamie