Re: something I don't get about the current plan...

On 18/11/13 7:14 AM, Willy Tarreau wrote:
> 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.
I disagree. With port 80, you have some chance of sneaking HTTP/2 by the 
firewall, so if HTTP/2 goes to port 100 there will be less HTTP/2 
initially. That is certain.

But there is no need at all for a timeout. Servers already have HTTP/1 
on port 80. They would be able to add HTTP/2 on port 100, so both 
services are available. Port 80 will be used by old clients and clients 
that are stuck behind old middleboxes, whereas port 100 will be used by 
new clients on the open Internet or behind new middleboxes.

A new client would start both connections at the same time. It will only 
give up on one of them after they receive a good reply from the other. 
And by "good reply" I don't mean ACK. I mean an HTTP response with 
actual content. So if all you get on port 80 is a redirect, you keep 
going on both ports until at least one has yielded actual content. This 
is similar to how many platforms do IPv6 vs IPv4, and it adds 
complexity, not latency.

There's no need to keep users waiting.


Received on Monday, 18 November 2013 08:50:24 UTC