Re: on DNS records

On Wed, Nov 14, 2012 at 02:37:51PM -0800, James M Snell wrote:
> On Wed, Nov 14, 2012 at 2:10 PM, Willy Tarreau <w@1wt.eu> wrote:
> 
> > [snip]
> >
> > Thus it's foolish to assume that a different protocol can be talked on port
> > 80 without prior upgrade.
> >
> > Using DNS to advertise a different port could be a solution to avoid the
> > HTTP Upgrade, because it could allow users to detect that HTTP/2.0 is
> > spoken natively on a specific port on the server. However it would still
> > not take into account the fact that client-side filtering on firewalls
> > and proxies generally don't allow unknown ports to pass.
> >
> >
> What I'm failing to understand is why the latter is really a problem. If we
> say that http/2 requires a new port, no matter what, the stuff in the
> middle is going to have to be reconfigured anyway to support http/2.
> Otherwise, we just fall back to http/1.

In how much time do you fall back ? That's the issue. For example, at
a customer, I was used to read my yahoo mails using http:// instead of
https:// because the https scheme was redirected to a dirty auth page
on the proxy. This is not a failure for the browser, there was some
valid contents in return for the request.

Fortunately I (the user) was offered the choice to click on the URL bar
and type "http://mail.yahoo.fr/" instead of letting the browser decide
for me. And being offered the choice is important.

Similarly, I've been used to click links to github which were https and
see them time out because the port was not opened. When I'm used to see
this from these locations, I know that I have to convert the link to http://
before even attempting to use https. If I let the browser try for me without
letting me choose, and each time I have to wait for a 10-second timeout, it
will be a terribly unpleasant experience.

> If the http/2 specific port is not
> open, then http/2 is not supported and that is that. It's a feature. Not a
> bug.

I'm not saying it's a bug either, I'm saying that I find it important that
the user is offered the choice of the transport to use to connect to the
site, as it has worked well for ages now.

> I guess I just don't buy in to the whole "It's gotta be port 80"
> argument.

I'm not saying this, I'm saying that on port 80 we must speak an HTTP/1
compatible protocol. HTTP/1 can fortunately be upgraded to 2.0 so we
should have no reason no to offer this since it significantly improves
end-user experience. We have possibilities to offer several ways to
connect at the user's choice and without breaking protocols nor triggering
issues with invisible products. Let's just assume that users know better
what site they can connect to than the hundred of engineers here.

Regards,
Willy

Received on Wednesday, 14 November 2012 22:57:53 UTC