Re: [hybi] #1: HTTP Compliance

[Willy Tarreau <[e-mail]>]

On Sun, Aug 15, 2010 at 12:55:32PM +0200, gustav trede wrote:
> On 15 August 2010 12:50, Willy Tarreau <[e-mail]> wrote:
> 
> > 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
> >
> > Its not the person, its the process of how ideas get formalized into the
> spec i was asking about.
> Discussions like the one going on now regarding a serious problem, is
> perhaps something that should happen before there is a magical decision to
> move an idea into the spec proposal ?.

It has happened, I've personally ben raising several HTTP incompatibilities
since January. Things are slowly making progress but there are security and
performance trade-offs to take into account, which don't make it easy to get
something which satisfies all needs.

What's important is that those issues don't get lost. Sal entered them into
the bug tracker.

Regards,
Willy