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