- From: Michael Sweet <msweet@apple.com>
- Date: Wed, 20 Nov 2013 09:58:56 -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 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…), 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…) _______________________________________________________________ Michael Sweet, Senior Printing System Engineer, PWG Chair
Received on Wednesday, 20 November 2013 14:59:33 UTC