Re: on DNS records

------ Original Message ------
From: "Willy Tarreau" <w@1wt.eu>
>On Wed, Nov 14, 2012 at 10:30:21PM +0000, Adrien W. de Croy wrote:
>
>>
>>
>>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?
>>
>
>
>yes, raw HTTP2 on dedicated default port.
>
>
>>
>>I'd suggest "http2://" as a scheme name will be unpopular, maybe
>>something more user-friendly for example "web://"
>>
>
>
>Possibly, yes.
>
>
>>
>>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.
>>
>
>
>But they already do. I really think that's a wrong argument we've already
>read here, because many of them are already used to have their application
>frameworks build the URLs automatically. They even ask us (the reverse-proxy
>guys) to provide some "X-Protocol: https" or "X-SSL: yes" to help them
>decide whether to emit "http://" or "https://" in all the pages the build.
>So the scheme is not that much of an issue, and certainly not a show-stopper.
>
>
>>
>>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.
>>
>
>
>I'm not sure I'm following you here :-/
>
>
>>
>>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.
>>
>
>
>We should really not put a MUST here, because it is already incompatible
>with plain IP addresses. How did you configure your WiFi router at home ?
>You certainly connected to http://192.168.1.1/ and you did not have a
>DNS yet. Quite frankly, I don't see what this DNS mess will bring, because
>everything is contained in the URI and the DNS only knows how the site is
>connected to the net, not how to reach it.
>
>
>>
>>This would then be extensible, and allow for other transport or
>>transfer protocols to be used for the web in future.
>>
>
>
>That's precisely what the scheme was made for ! Define what transport
>protocol to use to fetch the resource.
>

this just comes down to who should define the transport / protocol and 
when.

If you say the protocol and transport are defined in the URI, then it's 
fixed, and if you wish to change protocol or transport, you need to 
change your URIs.

If you adopt an approach where transport and protocol can be 
discovered, then you can change protocol or transport without needing 
to change URIs.

My proposal was just a way of making transport and transfer protocol be 
discoverable (e.g. queried by DNS).  This way a server operator can 
upgrade their server without involving the people who have content 
hosted on it.

Adrien
>
>
>Willy
>
>
>
>

Received on Wednesday, 14 November 2012 23:19:10 UTC