- From: Willy Tarreau <w@1wt.eu>
- Date: Mon, 20 Aug 2012 10:49:53 +0200
- To: Julian Reschke <julian.reschke@gmx.de>
- Cc: Yoav Nir <ynir@checkpoint.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
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. 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. Best regards, Willy
Received on Monday, 20 August 2012 08:50:29 UTC