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

Re: HTTP 1.1 --> 2.0 Upgrade

From: Julian Reschke <julian.reschke@gmx.de>
Date: Mon, 20 Aug 2012 10:25:46 +0200
Message-ID: <5031F48A.2050608@gmx.de>
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 GMT

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