Re: on DNS records

On 15.11.2012 11:47, Willy Tarreau wrote:
> 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),

Maybe. If so it is on another table over that way --->

This thread needs to handle the case that the client for whatever 
reason has chosen to use only an http:// URL and DNS to fetch the 
content *and* opts not to Upgrade:.

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

Might as well redefine HTML to use gopher:// to fetch that XML/JSON 
data, and urn:// on multimedia then. No I'm not joking. Both are 
individually more efficient at that type of transfer than HTTP 
messaging. What is the use of retaining HTTP/1.x semantics if a 
completely different protocol, different scheme, different port is going 
to be the outcome?


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

The best one I have seen was a request for "Via: 1.1 example.com:443 
(HTTPS)" - which *is* a reasonable extension of Via when you think about 
it being completely agnostic to the particular port in use. Although 
even better would be: "Via: HTTP/1.1 example.com:443 (TLS)" which gives 
transparency about the scheme and transport layer combinations as well.

That said the "//example.com/" page URL syntax is a wonderful boon to 
my developer side-life. Unfortunately RFC 2616 requires an absolute URL 
in Location: headers, so a lot of frameworks and custom scripts do not 
support sending it back on redirects.

AYJ

Received on Thursday, 15 November 2012 01:32:36 UTC