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:46:58 -0500
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>
Message-id: <47293C60-CC35-4AF5-B49D-547956AD1C68@apple.com>
To: Poul-Henning Kamp <phk@phk.freebsd.dk>

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

    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

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