- From: Julian Reschke <julian.reschke@gmx.de>
- Date: Mon, 20 Aug 2012 10:25:46 +0200
- To: Yoav Nir <ynir@checkpoint.com>
- CC: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
On 2012-08-20 10:16, Yoav Nir wrote: > 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. There's already an "Upgrade" header field for that. > 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. I don't think we need a new mechanism here; we already have "Upgrade" as a request header field. > 4. The client also caches that this server supports HTTP/2.0. Next > time, it won't need the upgrade mechanism. How does the recipient then know that the message is HTTP/2.0? > .... Best regards, Julian
Received on Monday, 20 August 2012 08:26:14 UTC