W3C home > Mailing lists > Public > ietf-http-wg@w3.org > July to September 2012

Re: HTTP 1.1 --> 2.0 Upgrade

From: Yoav Nir <ynir@checkpoint.com>
Date: Mon, 20 Aug 2012 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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 20 August 2012 08:50:49 GMT