Re: on DNS records

If we had change of scheme on the table (which I don't think we do), 
and possible change of port, then need it be http at all?

e.g. are we then talking about new protocol on new port?

I'd suggest "http2://" as a scheme name will be unpopular, maybe 
something more user-friendly for example "web://"

I think also in the unlikely event that such a proposal went any 
further, we could look at a new way to determine how to connect etc.

Web content authors don't want to be concerned about the protocol used 
to deliver their pages.

So any new scheme would need to take that out of the hands of the 
content author, and would therefore need to allow use of http/1.1, 
http/1.1/tls, http2, ftp, ldap, newproto etc etc.

If the spec required that to connect for a web:// URL the client must 
do a DNS WEB (new RR) record lookup, which could then specify 
transport, port and server name then all this could be published by the 
site operator.

This would then be extensible, and allow for other transport or 
transfer protocols to be used for the web in future.

Adrien

------ Original Message ------
From: "Willy Tarreau" <w@1wt.eu>
To: "Eliot Lear" <lear@cisco.com>
Cc: "Martin Thomson" <martin.thomson@gmail.com>;"Adrien W. de Croy" 
<adrien@qbik.com>;"ietf-http-wg@w3.org Group" <ietf-http-wg@w3.org>
Sent: 15/11/2012 11:10:15 a.m.
Subject: Re: on DNS records
>On Wed, Nov 14, 2012 at 08:18:45PM +0100, Eliot Lear wrote:
>
>>
>>Martin,
>>On 11/14/12 8:13 PM, Martin Thomson wrote:
>>> On 14 November 2012 11:09, Eliot Lear <lear@cisco.com> wrote:
>>>> That's a fair point.  Question: how would you handle SRV with
>>>> http://www.example.com:49080?
>>> That was raised in the meeting.  SRV isn't enough for that reason
>>> alone.  I know too many hosts that operate on different ports.
>>> Obviously, each port could be given a new name, but that eventually
>>> leads to an increase in the number of wildcard certificates out there.
>>>
>>>
>>
>>Thanks.  So you would prefer some other record that simply indicates
>>what version runs on what port and dump transport protocol?  What do
>>others think?
>>
>
>
>That was one of the issue I raised several times a few months ago
>explaining why I think DNS alone cannot be a solution.
>
>The problem we have with DNS is that it's only server-centric. One single
>authority decides what to advertise as the way to connect to their site.
>That can work for new ports. But not for port 80. The reason is that on
>port 80, you have many components along the chain doing many things such
>as simple protocol inspection, load balancing, proxying, caching, etc...
>that neither the server not the client sides are aware of !
>
>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.
>
>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/ <safelink(12103c78-49e7-4542-85ee-aa0bc2755e19):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
>
>
>
>

Received on Wednesday, 14 November 2012 22:30:34 UTC