Re: [hybi] #1: HTTP Compliance

[gustav trede <[e-mail]>]

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

regards
  gustav