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: Wed, 20 Nov 2013 16:11:57 +0100
To: Michael Sweet <msweet@apple.com>
Cc: 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: <20131120151157.GB8581@1wt.eu>
On Wed, Nov 20, 2013 at 09:58:56AM -0500, Michael Sweet wrote:
> Willy,
> 
> On Nov 20, 2013, at 4:03 AM, Willy Tarreau <w@1wt.eu> wrote:
> > ...
> > Note that I'm regularly reading here that Upgrade always wastes a
> > round trip, which is wrong. First, when the browser knows that the
> > destination supports Upgrade, it can send the payload immediately
> > after the headers. Second, 101 is an interim response meaning that
> > the complete response is supposed to follow. So if you send something
> > like "OPTIONS * HTTP/1.1\r\nUpgrade: HTTP/2.0\r\n..." it will need
> > a round trip because we won't get any data with 101. But if you send
> > "GET / HTTP/1.1\r\nUpgrade: 2.0\r\n", the server must reply to this
> > request and provide the contents. The response can very well look
> > exactly like a server push in practice, in that from a 2.0 point
> > of view, the server sends first.
> 
> It is my understanding from prior comments that the GET-with-upgrade method
> does not work with some/many proxies (I?m still waiting to hear which ones?),

All those who didn't understand from 2616/2817 how it was supposed to be
used. Haproxy in versions prior to 1.3 was one of those. I've seen a number
of nginx, apache and squid versions not support it either. Packet-based
load balancers are even more affected (eg: Alteon used to be, never tried
versions after 22.x). That said, many of them tend to behave the same way
and simply ignore the Upgrade header without removing it. Those which
rebuild a new request cause no trouble, they just don't support the upgrade
(apache/nginx/squid were in this category and did not hang). Old haproxy
versions would simply let the 101 pass and would either let the rest pass
through or close the connection after the 101 message. Packet based products
are really the worst ones.

> so doing a GET that advertises the capability (without the Connection:
> upgrade header) and following up with an OPTIONS request when the server?s
> response also includes Upgrade: HTTP/2.0 might be the best we can reliably do
> (but still a lot better than opening dozens of parallel connections to get
> the page?s linked resources?)

In my opinion, advertising the capability will not provide anything since
the problematic devices are the non-compliant ones which will ignore your
advertisement. Upgrade easily allows both ends to agree on what they both
support, they just don't know that there's some crap in the middle.

Willy
Received on Wednesday, 20 November 2013 15:12:34 UTC

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