Technically speaking, adding a period at the end of a URL is valid in that it implicitly exists for all URLs in the context of DNS. Your browser doesn't care however and while not exactly niche, I don't think it's widely known either. Funnily enough, typing a URL" "correctly" such as https://amazon.com. (make sure to include the trailing dot!) can actually cause some load balancers to freak out and serve no or even garbled content! It's pretty neat and this is definitely a tangent. Either way, you don't want your camera mucking with the contents of a QR code
> Technically speaking, adding a period at the end of a URL is valid in that it implicitly exists for all URLs in the context of DNS.
I think your are confusing the role of a trailing dot in the DNS[1] system with the role of a host element in a URI[2].
So, technically speaking, adding a period at the end of a URL is really not OK because `https://example.com/index.html` and `https://example.com/index.html.` are different resources. (note that HN's URL linking logic omits the trailing dot.)
> The rightmost domain label of a fully qualified domain name in DNS may be followed by a single "." and should be if it is necessary to distinguish between the complete domain name and some local domain.
but there is no reason to expect that adding a period at the end of any old URI is going to work.
Although it is valid in DNS, it is not valid in the TLS SNI. If you tell the remote server you wanted some.name.example. with that extra dot at the end that's an error and it should tell you to go away.
All the names in SNI should be real names and not some locally qualified name, the alternative would be confusing because these are identities and so it doesn't mean anything to have proof you're really "testserver4" we want to know whether you're really "testserver4.mycorp.example" or not.
“testserver4.mycorp.example” (no trailing dot) is not fully-qualified and as such could refer to any number of things of differing identities, e.g. “testserver4.mycorp.example.atthomenetwork.com”.
On the other hand, “testserver4.mycorp.example.” (trailing dot) is fully-qualified and is not an ambiguous identity.
> “testserver4.mycorp.example” (no trailing dot) is not fully-qualified and as such could refer to any number of things of differing identities, e.g. “testserver4.mycorp.example.atthomenetwork.com”.
Whether a domain is fully qualified depends on the application. There's no universal syntax. The trailing dot is merely an interface convention followed by some applications to allow the user to indicate that the domain name is complete. It's only useful for applications that don't always deal with fully qualified domains, and perhaps ones that deal with top level domains.
User interfaces MAY provide a method for users to enter
abbreviations for commonly-used names. [..]
If an abbreviation method is provided, then:
(a) There MUST be some convention for denoting that a name
is already complete, so that the abbreviation method(s)
are suppressed. A trailing dot is the usual method.
If you add trailing dots where the dns root would be implied anyway, this could be regarded as an "over-qualified" name. It is considered an error. For example in SMTP. RFC1123 5.2.18 Common Address Formatting Errors:
o Some systems over-qualify domain names by adding a
trailing dot to some or all domain names in addresses or
message-ids. This violates RFC-822 syntax.
RFC822 says "The root node is common to all addresses; consequently, it is not referenced."
Since SNI always uses fully qualified domain names, there is no purpose to having a trailing dot.
Right, so under your approach they need to add a dot, every single time. This wastes a byte during the handshake, in order to transport the dot which you've decided must be there. Whereas the approach they actually shipped does not waste that byte.
If it makes you more comfortable pretend it's an amazing "compression scheme" where they omit that extra byte with a dot in it to save space.
See also IEEE 754 floating point where that first 1 in your binary floating point number is omitted entirely because it's implied and so writing it into the 32-bit value anyway would waste an entire order of magnitude.
The comment to which I was replying said "the end of the URL". Adding the period at the end of the domain name is not the same as adding it at the end of the URL. I responded to what was actually said.
Nginx and Apache handle this just fine, as does Google's, Microsoft's and Facebook's infra.
It's only hipster services such as traefik and caddy that can't handle this. There's a long standing bug on the caddy bugtracker for this, which got closed as wontfix: working as intended.
That's really unfortunate, the trailing dot indicates that it is a fully qualified domain name and I've used this when writing tests, for example, to ensure that a hostname either resolves to some internally served DNS label _or none at all_.
Or when you're writing a thumbnail generator bot that's supposed to generate previews of webpages, but you want to ensure domains aren't resolved relative to your local search domain.
The "fix" seems to be modifying the client you use to trim suffixed dots from the Host header and SNI. But it'd be much simpler if Caddy & Traefik would juat comply with the standards.
See, now I have to wonder if you put 'all_.' as full stop to your written sentence, or as part of a FQ pseudo code in online forum style with no grammatical punctuation. AHHHH!!!
My QA found this out recently - he'd accidentally typed a . at the end of the URL for one of our test servers which ended up breaking CORS - it certainly took us a while to figure that one out.
It's not period at the end, article claims it modifies domain names and subdomains, e.g. www2.example.edu into www.2.examp.le.edu, supposedly when it could match `www` or a second level domain.
