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