- From: Yoav Nir <ynir@checkpoint.com>
- Date: 2012年8月20日 11:50:18 +0300
- To: Julian Reschke <julian.reschke@gmx.de>
- CC: "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
- Message-ID: <4623CB2E-7E5B-47BD-BE58-9AEAA2211940@checkpoint.com>
On Aug 20, 2012, at 11:25 AM, Julian Reschke wrote: > 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. I was going to say that "Upgrade" is so rarely used, there may be buggy implementations out there that will balk at seeing this. But since websockets uses the upgrade mechanism, I guess that problem is solved by now. >> 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. Agree. >> 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? Remains to be seen what HTTP/2.0 will actually look like, but SPDY-00 is very easily distinguishable from HTTP/1.x. Connections start with control frames, and control frames have the high bit on the first octet set. HTTP/1.1 requests tend to have ASCII characters at the start. I think a heuristic approach to telling HTTP/1.x from HTTP/2.x is good enough for the servers. Yoav
Received on Monday, 20 August 2012 08:50:43 UTC