Re: on DNS records

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. 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 guess I just don't buy in to the whole "It's gotta be port 80"
argument.

- James


> A new problem with advertising random ports in DNS records is that it
> would be much harder to gain unfiltered access than by advertising only
> a standardized port. And if we have a standard port we don't need to
> advertise the port in the DNS record.
>
> Ports still cause two new troubles :
>   - how to decide what protocol version to use on port XYZ ? (I've seen
>     Phillip's proposal, I still think that another natural solution would
>     be a dedicated scheme)
>
>   - how can we know that the new port it controlled by the same authorities
>     as ports 80/443 along the whole path ?
>
> I'm still thinking that we should do more research on the scheme :
>
>    - keep "http://" as the default scheme which MUST only speak HTTP/1.x
>      because that has always been the case. A temptative Upgrade to 2.0
>      is encouraged but both the clients and the server know that this
>      upgrade is optional, may fail and the traffic may remain HTTP/1.
>
>    - have "https://" use the TLS NPN extension to announce support for
>      the protocol on both sides. I should say on "all" sides, because TLS
>      is a transport protocol and as such is hop-by-hop : if intercepted,
>      the interceptor's capabilities are used. At least this has proved to
>      work well for SPDY and I don't see why we should refrain from using
>      this for HTTP/2.
>
>    - have "http2://" as the optimal replacement scheme for the long term,
>      on a dedicated well-known port. To the opponents of the new scheme,
>      I would say that this has worked for http->https, and I don't see
>      any reason for this not to work again, quite the opposite. In fact,
>      there would be much incentive to migrate to support this scheme as
>      there would possibly be some performance benefits by doing so. And
>      just like many web sites still support https and http for the few
>      https-impaired users, we would have https/http2 by default, and
>      http as the fallback for those who can only use port 80.
>
> Obviously the switch will take time, a few years to get a fairly common
> adoption, but this way we're sure to always provide an upgradable path
> from HTTP/1, and without breaking what has been assumed for decades (eg:
> http://x.y.z:port/ is http and not anything else, then we'd equally
> have http2://x.y.z:port/ be http2 and not http).
>
> So in the end, we'd get the following possibilities to connect to a web
> site from a user agent :
>
>   - if scheme is "https://", use the best HTTP version advertised as NPN
>     by the server ;
>
>   - if scheme is "http2://", use raw HTTP/2 exclusively over the designated
>     port and report an error if it fails (as we do right now with https).
>     THIS is what will drive quick opening of the new port on the client
> side.
>
>   - if scheme is "http://", attempt an 1.1->2.0 Upgrade over the
> designated
>     port, with the possibility that it will remain 1.x only.
>
> Regards,
> Willy
>
>
>