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 20:29:04 +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: <20131120192904.GQ8581@1wt.eu>
On Wed, Nov 20, 2013 at 02:17:32PM -0500, Michael Sweet wrote:
> > 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 -

I know, that's the easiest case, which happens with 1.1-compliant products.

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

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

I remember one issue was reported with an anti-virus software running on the
client, f-secure something I believe but I could be wrong. It did the dirty
thing, ignore Upgrade, pass it silently and expect data after the 101 without
letting anything else pass through.

We should keep in mind that when we talk about websocket failures, we indeed
talk about failures to Upgrade to WS whatever the cause. We'll have the same
failure rate, except that in our case, processing the 1.1 request normally
is the expected fallback method (it was not acceptable for WS).

Regards,
Willy
Received on Wednesday, 20 November 2013 19:29:41 UTC

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