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 09:52:10 +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: <20131121075210.GA32541@LK-Perkele-VII>
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?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).
- FIN (EOF) after upgrade attempt.
- RST (ECONNRESET) after upgrade attempt.
- The connection hangs after upgrade attempt.
- 101 response is given but the connection then hangs.
- 101 response followed by server response is given, half-link to server is
  hung.
- 101 response is given, followed by HTTP/1.1 4xx/5xx error.

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

-Ilari
Received on Thursday, 21 November 2013 07:52:37 UTC

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