- From: Willy Tarreau <w@1wt.eu>
- Date: Mon, 18 Nov 2013 06:14:03 +0100
- To: Roland Zink <roland@zinks.de>
- Cc: ietf-http-wg@w3.org
On Sun, Nov 17, 2013 at 06:56:37PM +0100, Roland Zink wrote: > 5) Using a separate port would help to separate HTTP/1 and HTTP/2 > infrastructures and will make the solution more reliable In theory you're right. In practice it is more difficult to get a new port working in the short term. While using an existing port immediately tells you the other part is not willing to upgrade (but will not always tell you so), another port will require a long timeout to expire before realizing that the port is closed. Worse, with some SYN-protection firewalls, the connection will establish but nothing will pass, making you think the connection to the server was possible and that the server is slow to respond. If we were to bother users and have them wait 5 seconds for each site they want to visit, we could do that. But they're not going to accept this at all, and even if it only affects a minority it will be an issue because they'll spread bad words about their last browser upgrade. BTW it does not affect only browsers. Git has its own port (9418) and still provides support for fetching over HTTP because it generally passes firewalls much better. And for the record, even here at home I had to unlock the port to use it. And the situation is even worse with mobile phone operators where basically nothing can pass through unless there's a transparent proxy to handle it, because the port would remain close until they find the product that do the MITM... In fact if we said "in 5 years HTTP/2 will start using port 100", we could expect that product designers would start supporting it and that by then most deployed devices would be replaced with something working. But for many, HTTP/2 is going to be ready tomorrow, not in 5 years. Regards, Willy
Received on Monday, 18 November 2013 05:14:26 UTC