W3C home > Mailing lists > Public > ietf-http-wg@w3.org > January to March 2016

Re: SNI vs Host: and a trailing dot

From: Michael Sweet <msweet@apple.com>
Date: Wed, 16 Mar 2016 09:15:38 -0400
Cc: Amos Jeffries <squid3@treenet.co.nz>
Message-id: <6B3389B1-12DB-4B67-9FC4-161599B7C623@apple.com>
To: ietf-http-wg@w3.org
One of the saddest workarounds present in CUPS is a hardcoded mapping of "localhost" to 127.0.0.1 and ::1 because "localhost.<defaultdomain>" often is assigned to the AD server leading to all sorts of wonderful problems...


> On Mar 16, 2016, at 9:02 AM, Willy Tarreau <w@1wt.eu> wrote:
> 
> Hi guys,
> 
> On Thu, Mar 17, 2016 at 01:44:24AM +1300, Amos Jeffries wrote:
>> On 17/03/2016 1:09 a.m., Michael Sweet wrote:
>>> FWIW, CUPS has traditionally stripped the trailing dot from both since most printers (and web sites, for that matter) have difficulty handling "example.com."
>>> 
>> 
>> 
>> FWIW; Squid likewise does that as well.
>> 
>> IIRC we determined that the trailing dot syntax was an outcome of people
>> partially understanding the DNS specifications. Those DNS specs talk
>> about using the trailing dot to terminate the domain labels. But on
>> close inspection it is only supposed to be used in the wire-format for
>> DNS packets. Intermediate representations like HTTP messages or TLS SNI
>> are expected to have no trailing dot for valid FQDN.
> 
> Not exactly because you have the problem when you need to differenciate
> host names that belong to your local domain and other ones. For example
> you could have a host called "www.example.com" on your local domain, and
> if you want to be sure to use the public www.example.com and not
> www.example.com.my.local.domain, the only way is to add the trailing dot.
> 
> I remember having been in this exact situation many years ago by which
> I couldn't connect to my default gateway's web interface until I realized
> that the name "gw" that I was using on my local network was first resolved
> as "gw.work.local" which was my company's groupware server and it couldn't
> be accessed from where I was located (hence my belief that the device did
> not respond). Simply passing "http://gw./" solved the issue for me.
> 
> However I have no idea where in the chain this dot needs to be trimmed,
> but it definitely has a use case for the end user and in HTTP URIs (though
> not frequent).
> 
> Cheers,
> Willy
> 
> 

_________________________________________________________
Michael Sweet, Senior Printing System Engineer
Received on Wednesday, 16 March 2016 13:16:13 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 22 March 2016 12:47:11 UTC