HTTP 1.1 --> 2.0 Upgrade

Hi

There's been a recent discussion about signaling support for HTTP 2.0 in the DNS. I think that is a good way to go about it, but it doesn't cover all cases.

I believe there is value in an upgrade mechanism, for example for home routers and other devices that use HTTP for configuration long before (if ever) they have DNS entries, let alone SRV records.  While such a mechanism may also be useful for HTTPS, something like NPN can be used as part of the TLS handshake.

So here's my proposal:


 1.  When first connecting to a website, the client begins with HTTP 1.0/1.1.
 2.  A server that supports HTTP/2.0 responds with a new header: "HTTP-VERSIONS: 1.1,2.0". This header is included in the server's response to the client's request.
 3.  The client uses a new pseudo-method "UPGRADE-TO_VER 2.0 HTTP/1.1\r\n\r\n". Everything following is HTTP/2.0. There can be headers there, but I don't see much need for any.
 4.  The client also caches that this server supports HTTP/2.0. Next time, it won't need the upgrade mechanism.
 5.  The server replies with a "HTTP/1.1 200 OK\r\n\r\n" and everything that follows is HTTP/2.0. Again there may be headers.

A related but orthogonal issue is finding out if the path between the client and the server supports HTTP/2.0. Fortunately, middleware does not tend to appear mid-path. It's usually either server-side (reverse proxies, load balancers) or it's a client-side firewall / proxy.  Server side should not concern us, because there's no point in configuring a server to support (and advertise through this header or a DNS record) that HTTP/2.0 is supported, when the load balancer blocks it. That's a clear misconfiguration. Client side middleware is either there or it's not. It's not likely to be present on-path to one generally available website while not being present for another.

One obvious way to find out, is to have some well-known site that supports HTTP/2.0 (browser vendors or others can run these sites). A client can perform a simple HTTP/2.0 GET from such a site whenever it starts, or whenever something in the network settings has changed (interface, IP address, next-hop router, routing table). The actual heuristics would have to be more involved, since we wouldn't want downtime on a single server to push a significant part of the web to HTTP/1.1.

If people find this idea interesting, I'd be happy to write it up in a draft.

Yoav