Re: HTTP 1.1 --> 2.0 Upgrade

On Aug 20, 2012, at 11:49 AM, Willy Tarreau wrote:

> On Mon, Aug 20, 2012 at 10:25:46AM +0200, 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.
> 
> +1.
> 
> All this work has been done over and over for WebSocket, I don't see
> why we need to reinvent the wheel.

Agree. I forgot that WebSocket uses Upgrade

> Upgrade was designed *exactly* for that purpose and fits it very well.
> Moreover it is the only one (along with NPN) which considers the
> intermediary chain, while side-band mechanisms (such as DNS) cannot
> take that into account.

Intermediaries generally leave unknown headers alone, so they will have to be upgraded to either identify (and remove) attempts to upgrade to 2.0, or else to support 2.0. It's possible that this work (by intermediaries) has already been done because of WebSockets, though.

NPN is different, because TLS proxies generally don't just pass along extensions they don't know about, so blocking the NPN extension effectively disables SPDY.

Yoav

Received on Monday, 20 August 2012 09:03:17 UTC