- From: Willy Tarreau <w@1wt.eu>
- Date: Thu, 26 Jan 2012 22:01:55 +0100
- To: Adrien de Croy <adrien@qbik.com>
- Cc: Poul-Henning Kamp <phk@phk.freebsd.dk>, Amos Jeffries <squid3@treenet.co.nz>, ietf-http-wg@w3.org
On Fri, Jan 27, 2012 at 09:46:43AM +1300, Adrien de Croy wrote: > > one other thing, I think we are losing site of context here. > > We're discussing possible features for a new protocol which is not > necessarily syntactically compatible with HTTP/1.x Indeed. > This means that every piece of deployed HTTP infrastructure would need > to be upgraded if it wishes to support the new protocol. > > So raising roadblocks for general protocol features on the basis of very > limited existing 1.x implementations serves no useful purpose. > > In that light, I'll throw something else out there. > > I think it may possibly solve more problems than it would create to > simply use a different port for "http 2.0", and not try to achieve > backward compatibility / interoperability with 1.x on the same port. The same subject was discussed to great extents on hybi, and the big problem with using a new port and/or with incompatible upgrades is that you enter a chicken-and-egg problem. Browsers won't use the new protocol by default until there is enough adoption on the server side, and server siders won't waste their time and money deploying and maintaining a second parallel infrastructure for years just for the few geeks around who click the "use fancy http" box. The current status of HTTP pipelining and TCP ECN describes the process very well. Due to the size of the current web, the only upgrade path seems to be by starting compatible and possibly upgrading, but in any case the failure must be immediate and clean, otherwise painful failures will result in the new version being disabled by default and enabled by noone. > There - I said it :) So did I :-) Willy
Received on Thursday, 26 January 2012 21:02:35 UTC