- From: Michael Sweet <msweet@apple.com>
- Date: Wed, 20 Nov 2013 09:46:58 -0500
- To: Poul-Henning Kamp <phk@phk.freebsd.dk>
- Cc: Mark Nottingham <mnot@mnot.net>, James M Snell <jasnell@gmail.com>, Bjoern Hoehrmann <derhoermi@gmx.net>, HTTP Working Group <ietf-http-wg@w3.org>
Poul-Henning,
On Nov 20, 2013, at 3:13 AM, Poul-Henning Kamp <phk@phk.freebsd.dk> wrote:
> ...
> 3. Leave port 80 as HTTP/1 only because there is too much "pidgin
> HTTP" kit out there, and the RTT delay spent on upgrading would
> prevent pure HTTP/2 implementations and delay when HTTP/2 performance
> benefits kicks in.
Again I call for names of proxies that break with HTTP/2.0 (or TLS) upgrade from HTTP/1.1. We (or at least *I*) need to test again them to a) confirm that the reliability issues are as bad as reported and b) determine whether there are alternate strategies that improve things, particularly delayed upgrade, with the client sending an OPTIONS request to do the upgrade after getting a response indicating that the other end supports HTTP/2.0:
Client Server
GET / HTTP/1.1
Host: server.example.com
Upgrade: HTTP/2.0
. . .
HTTP/1.1 200 OK
Content-Length: 1234
Content-Type: text/html
Upgrade: HTTP/2.0
. . .
<<content>>
OPTIONS * HTTP/1.1
Host: server.example.com
Connection: upgrade
Upgrade: HTTP/2.0
HTTP2-Settings: <base64url encoding of HTTP/2.0 SETTINGS payload>
HTTP/1.1 101 Switching Protocols
Connection: upgrade
Upgrade: HTTP/2.0
[ HTTP/2.0 connection ...
This strategy would basically mean that single request clients would only ever use HTTP/1.1, at least for http:// URIs.
Also, the RTT delay for an OPTIONS request from the client to upgrade to HTTP/2.0 will be less than the RTT delay for dozens of TCP connections starting up to grab page resources separately. And doing so is much more server and network friendly, don’t you think?
_______________________________________________________________
Michael Sweet, Senior Printing System Engineer, PWG Chair
Received on Wednesday, 20 November 2013 14:47:30 UTC