W3C home > Mailing lists > Public > ietf-http-wg@w3.org > October to December 2013

Re: Call for Proposals re: #314 HTTP2 and http:// URIs on the "open" internet

From: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Date: Thu, 21 Nov 2013 11:34:01 +0200
To: Willy Tarreau <w@1wt.eu>
Cc: Michael Sweet <msweet@apple.com>, Poul-Henning Kamp <phk@phk.freebsd.dk>, Adrien de Croy <adrien@qbik.com>, James M Snell <jasnell@gmail.com>, Mark Nottingham <mnot@mnot.net>, Bjoern Hoehrmann <derhoermi@gmx.net>, HTTP Working Group <ietf-http-wg@w3.org>
Message-ID: <20131121093401.GA1296@LK-Perkele-VII>
On Thu, Nov 21, 2013 at 09:20:16AM +0100, Willy Tarreau wrote:
> Hi Ilari,
> 
> On Thu, Nov 21, 2013 at 09:52:10AM +0200, Ilari Liusvaara wrote:
> > On Wed, Nov 20, 2013 at 08:29:04PM +0100, Willy Tarreau wrote:
> > > On Wed, Nov 20, 2013 at 02:17:32PM -0500, Michael Sweet wrote:
> > 
> > Actually, isn't the "global" upgrade case pretty much all-or-nothing (w.r.t
> > severs that support HTTP/2.0)? That is, middleware either screws pretty much
> > any upgrade or it screws up none ("local" destinations may not go through it)?
> 
> I don't understand what you mean. A given middlebox will generally screw up all
> similarly-behaving connections the same way. However not all middleboxes will
> screw up the same way. For example if a middlebox prevents queued data from the
> client to flow to the server, it will only cause trouble to the clients which
> don't do a round trip first.

That's what I meant. Different middleboxes screw things up in different way, but
generally the same middlebox screws everything passing through it the same way.
 
> > - 101 response is given, followed by HTTP/1.1 4xx/5xx error.
> 
> Yes when the client pushes data to the server, believing the channel
> is clean. Generally a "400 bad request" or a "408 request timeout"
> can happen if the middlebox waits for a second valid request. This
> is the reason why in WS I preferred that we put "connection:close"
> in the exchanges (to incite middleboxes to close when non-compliant),
> but since I failed to make up that specific case again, I could not
> defend it anymore :-)

The process I considered to cause this was more like:

The middlebox passes the upgrade but doesn't process it (also passing
the 101). Thinks that the connection is still HTTP/1.1. Then the client
sends connnection magic, which of course causes things blows up...

Yeah, really broken proxy...


-Ilari
Received on Thursday, 21 November 2013 09:34:30 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 1 March 2016 11:11:19 UTC