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 09:58:56 -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: <D9C78AEF-E608-4670-BBC5-2056BBD98A6B@apple.com>
To: Willy Tarreau <w@1wt.eu>

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

This archive was generated by hypermail 2.4.0 : Thursday, 2 February 2023 18:43:39 UTC