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: Michael Sweet <msweet@apple.com>
Date: Wed, 20 Nov 2013 14:17:32 -0500
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: <9798A9B9-2250-4A99-A2E7-EAA724A04DAC@apple.com>
To: Willy Tarreau <w@1wt.eu>

On Nov 20, 2013, at 10:11 AM, Willy Tarreau <w@1wt.eu> wrote:
> ...
>> 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.

Well, if the serverís Upgrade header is filtered, and/or if the server only includes the Upgrade header if the client (or intermediate proxy) supplies it, then we donít have an interoperability/compatibility problem - 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.

Iíll see what I can find out with the proxies you mentioned to determine what level of functionality is available with current software - broken, HTTP/1.1 only, or compatible w/HTTP/2.0.

Michael Sweet, Senior Printing System Engineer, PWG Chair
Received on Wednesday, 20 November 2013 19:18:02 UTC

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