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: Willy Tarreau <w@1wt.eu>
Date: Thu, 21 Nov 2013 09:20:16 +0100
To: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
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: <20131121082016.GD22603@1wt.eu>
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:
> >
> > > with my
> > > proposed delay-upgrade strategy the client only attempts to upgrade when the
> > > response from the server indicates that it supports HTTP/2.0.
> > 
> > Ah OK I didn't catch what you meant. Sure this is what is needed at least for
> > the first connection attempt. If the browser keeps a cache of successful
> > destinations, it can later decide not to wait for the response and upgrade
> > right after the headers. I believe some browsers (Opera?) did this for
> > pipelining, though I may be wrong.
> 
> 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.

> > > I?ll see what I can find out with the proxies you mentiogned to determine
> > > what level of functionality is available with current software - broken,
> > > HTTP/1.1 only, or compatible w/HTTP/2.0.
> > 
> > At the moment, to the best of my knowledge, none of them is broken. We tried
> > hard to get some failure cases during the work on WebSocket, and we ended up
> > with this upgrade precisely because it failed cleanly with the software we
> > had access to.
> 
> The failure modes that spring to mind (not that I know any products that fail
> in these ways):
> 
> - Upgrade results 2xx response (HTTP/1.1).
> - Upgrade results 3xx response (HTTP/1.1).
> - Upgrade results 4xx error (HTTP/1.1).
> - Upgrade results 5xx error (HTTP/1.1).

The way you describe it is ambiguous here, because these results
may either be the valid ones from the origin server or may be emitted
by the middlebox itself. I expect most deployed products to result in
this above, where the Upgrade header field is removed and the response
comes in 1.1 from the origin server.

> - FIN (EOF) after upgrade attempt.

Yes, generally just after the 101 response headers. I don't expect
to see many of them over the internet though, because this would
come from those which do not support 101 nor keep-alive, and the
latter is not realistic over the internet as an intercepting proxy,
since it degrades performance.

> - RST (ECONNRESET) after upgrade attempt.

Can also come from those with a non-compliant IPS installed in front.

> - The connection hangs after upgrade attempt.

That can happen if content-length is advertised by the client. This
is a good reason for avoiding to start the upgrade with a POST/PUT.
I believe this is noted somewhere in the draft/wiki or was discussed
here.

> - 101 response is given but the connection then hangs.

This one can happen when 101 is not understood as an interim response.
The middlebox considers it final, sees no content-length and expects
to read more until the server closes.

> - 101 response followed by server response is given, half-link to server is
>   hung.

For me it is the same as above.

> - 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 :-)

> Of course, there might be other failure cases too...
> 
> The "hung" cases are the nastiest here. Pretty all other responses should
> come very quickly (on order of few tens of milliseconds, except the
> ones involving 101, which might be on order of few hundred milliseconds).

Yes absolutely.

Regards,
Willy
Received on Thursday, 21 November 2013 08:21:29 UTC

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