Re: [hybi] #1: HTTP Compliance

[Willy Tarreau <[e-mail]>]

On Wed, Jul 21, 2010 at 10:54:47PM +0000, Ian Hickson wrote:
> On Wed, 21 Jul 2010, John Tamplin wrote:
> > On Mon, May 17, 2010 at 5:29 AM, Maciej Stachowiak <[e-mail]> wrote:
> > > 
> > > Ian has claimed that the extra bytes after the request help WebSocket 
> > > fail early in the face of unaware proxies, though we do not yet have 
> > > data showing this to be the case. We do know that without this, often 
> > > the handshake will appear to succeed but transmitting messages will 
> > > fail, for the network setups of many users.
> > >
> > > I don't think anyone has indicated a practical problem caused by the 
> > > extra bytes.
> > 
> > I believe we have already had a real-world practical case where they did 
> > cause a problem:
> > 
> >    - client sends WebSocket request that goes through a proxy, random bytes
> >    are not advertised in the Content-length
> >    - proxy doesn't know WebSocket, passes along connection to real server
> >    which does implement WebSocket
> >    - server waits reading random bytes which were not forwarded
> >    - server drops the connection after a timeout
> 
> Success! :-)

I fail to see how failing through perfectly valid components can be qualified
as a success. It really seems that your goal is to ensure a general failure :-(

> > Thus the random bytes did succeed in preventing a WebSocket connection 
> > across a non-WS compliant proxy, but:
> > 
> >    1. the proxy was actually capable of forwarding the connection if the
> >    server had completed the request
> 
> That's easy to resolve. The simplest solution that comes to mind is having 
> the server send back the 101 straight away, and having the proxy send the 
> bytes on as soon as it sees the 101.

Ah goodness, it sounds like you finally got that one !

> (Note: from a conformance standpoint, the "server" includes the proxy.)

as seen from the client, yes. As seen from the proxy or the server or any
intermediate between them, no :-)

> >    2. we had to wait for a timeout, so this was not a fast-fail situation
> 
> Fast-fail is ideal, but not really necessary (there's plenty of other 
> situations that fail very slowly). We just don't want false positives. If 
> there's a way of tweaking the protocol so we don't get false positives, 
> and still fulfills our other requirements, but that fails faster, that 
> would be great.

Please check my proposal in a separate mail. I should detect more unreliable
components, work through more reliable ones and avoid one round-trip.

Willy