- From: Willy Tarreau <w@1wt.eu>
- Date: Thu, 5 Apr 2012 12:07:16 +0200
- To: "Adrien W. de Croy" <adrien@qbik.com>
- Cc: Eliot Lear <lear@cisco.com>, "ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
On Thu, Apr 05, 2012 at 09:45:01AM +0000, Adrien W. de Croy wrote: > There are a bunch of issues related to either keeping the same port or > choosing another. > > One argument is that getting a new port opened on a firewall can take a > long time, due to various issues. One of these issues is ability to > control. Indeed. > However, until firewall software is updated, it won't be able > to control upgraded traffic over port 80 anyway, except for maybe > breaking the upgrade mechanism. If we apply a correct fallback to 1.1, your product will still be able to control the traffic as 1.1. This is why I think that it is very important to be backwards compatible with 1.1 : the upgrade is the most transparent possible and admins have no reason to explicitly block it. If we're not compatible, many admins will not make the effort of opening the new port since it will require equipments they don't have. > In fact I think there will be a bunch of intermediaries (mainly CPE) > that will break the upgrade. I know earlier versions of WinGate didn't > strip headers matching Connection tokens, so would pass the Upgrade > through, and the 101 back, but barf on the new protocol. > > I also suspect there is a plethora of cheap DSL/NAT routers which do > port 80 inspection which may break. Whether they break in a way that > prevents operation or not is another matter. Don't forget that WebSocket readily uses this mechanism and that such bugs are already being reported to vendors. By the time we ship HTTP/2.0 a number of these implementation bugs will have been fixed, and not everyone will have deployed V2 anyway. Regards, Willy
Received on Thursday, 5 April 2012 10:07:53 UTC