Re: on DNS records

On 14.11.2012 23:37, James M Snell wrote:
>
> On Wed, Nov 14, 2012 at 2:10 PM, Willy Tarreau <w@1wt.eu 
> <mailto: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
I think the argument is that with a default port for http/2 it is 
possible to reconfigure existing equipment like firewalls. With 
arbitrary ports the administrator has no possibility to allow direct 
http/2 traffic. For intermediaries which don't see the DNS traffic it 
will be difficult to detect http/2 without a known port for it.

- Roland

>     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
>
>
>