Re: [hybi] #1: HTTP Compliance

[Willy Tarreau <[e-mail]>]

On Sun, Aug 15, 2010 at 12:24:38PM +0200, gustav trede wrote:
> On 15 August 2010 12:07, Willy Tarreau <[e-mail]> wrote:
> 
> > On Sun, Aug 15, 2010 at 05:10:09AM -0400, Shelby Moore wrote:
> > > An HTTP proxy that is compatible with draft/proposal #76 (the contentious
> > > one that passes 8 extra characters after the HTTP header without a
> > > Content-Length header), would need a specific code path for the WebSocket
> > > upgrade request in order to pass 8, and only 8, extra characters
> > > (concensus is that passing an arbitrary content length would be a
> > security
> > > hole).
> > >
> > > Isn't it the antithesis of the 80/20 rule and interoperability to require
> > > every HTTP proxy in the world to have specific code path for every
> > > possible future HTTP Upgrade protocol that comes along?
> >
> > it's even worse than that, it means that such a reverse-proxy, when shared
> > between HTTP and Websocket, will have to accept to blindly forward those 8
> > bytes everytime someones *pretends* to talk websocket, without the server's
> > consent.
> >
> > Since reverse-proxies are used everywhere (in IDS, HTTP-aware firewalls,
> > caches, load balancers, etc...), it is not even advisable to have per-host
> > or per-IP rules considering the large number of hosts that can be installed
> > behind any of them.
> >
> > So it is very important that if we go the HTTP way, we respect the
> > protocol's
> > semantics.
> >
> > In fact, the protocol can be made HTTP compliant by switching two lines in
> > the description of the server's behaviour : the server just has to send the
> > 101 *BEFORE* it reads the /key3/ parameter, and we're done.
> >
> >
> So how come that several technical unsound ideas that more or less originate
> from one person is ending up in the spec proposal in the first place ?.

You can't blame one single person for proposing something that does not
happen to work in some circumstances. If everything was that simple, the
proposal would already have become a spec. One of the goal of the single
person was to ensure that we'd get quick failures through incompatible
intermediaries. Achieving this means we may play on the border line of
the protocol. As long as no problem is identified, there's nothing wrong.
It's once the problem is identified that we must fix it and get back to
the compliant side of the protocol.

Regards,
Willy