Re: Call for Proposals re: #314 HTTP2 and http:// URIs on the "open" internet

Part of the problem is that it is extremely difficult to find out which
proxies are doing what given that they are implicit(ly somewhere in the
path). There is, however, evidence of this pain amongst folks who attempted
to use WebSockets over port 80.

-=R
On Nov 20, 2013 6:50 AM, "Michael Sweet" <msweet@apple.com> wrote:

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