It is not a textual match, and this is observable at multiple points in the process. It is therefore a different hostname. It’s that simple.
When I said “almost always”, I was referring to search domains as the exception, I just didn’t think it worth clarifying (though I was amused by the fact that it’s the oft-broken-at-HTTP-and-above one that’s reliable at DNS).
Look, the difference is trivially demonstrated and eCa’s original claim trivially falsified: unless you’ve gone out of your way already, at https://news.ycombinator.com/ you’re logged in, at https://news.ycombinator.com./ you’re not logged in, because the hostname and thus origin is different, and also they’re not same-site, and thus cookies and such are not shared.
ai and www.ai might serve the same content, might have one redirect to the other, might serve different content: they’re different hostnames and different origins, they can do what they like and it’s no bug in anything. ai and ai. might serve the same content, might have one redirect to the other, might serve different content: they’re different hostnames and different origins, they can do what they like and it’s no bug in anything.
> It is not a textual match, and this is observable at multiple points in the process. It is therefore a different hostname. It’s that simple.
Except that it is, in fact, the same hostname. "It's that simple." This is defined by DNS. Go open Wireshark and run `dig google.com @8.8.8.8 +nocookie` versus `dig google.com. @8.8.8.8 +nocookie`. Observe that the queries are identical other than the "Transaction ID" (and perhaps some IP or UDP-level randomness).
Application-level software can get it wrong, but it is in fact the same hostname at a level that pretty much everyone uses.
Application-level software getting it wrong does not invalidate that fact.
You can not adopt an identifier from some other protocol, and then use it with a different meaning, without a bug.
(Tangentially, this is why naming shouldn't be handled at the application layer, since it's already handled at lower levels. It's quite sad that no one wants to start moving HTTP towards SRV records.)
> I was referring to search domains as the exception
Yes, I assumed so, but as I pointed out, this would lead to the common one (news.ycombinator.com) being broken while the other (news.ycombinator.com.) would work (or else be broken by an application-layer bug, i.e. processing of the Host header causing it to break)!
> ai and ai. might ... have one redirect to the other, might serve different content
Then they would be broken. They are the same hostname and the same origin. They can not do what they like because there's no way they could resolve to a different address.
(And, as above, to do so would actually lead to the site being inaccessible for some people with search domains, since `ai` might actually be used as a subdomain, and `ai.` would still work for them but for a faulty application-layer configuration)
They are different hostnames. One is fully-qualified, the other is not. That the relative one is almost certain to resolve to the same as the fully-qualified is irrelevant. The fully-qualified one has an extra label. This makes it different. If you model hostnames in your type system, it would obviously be wrong for example and example. to compare as equal.
> Then they would be broken. They are the same hostname and the same origin. They can not do what they like because there's no way they could resolve to a different address.
You’re arguing against facts that I have already clearly demonstrated. It’s messy that the FQDN and relative forms are exposed in this way, and it would be nice if that had never happened, but they are exposed, and claiming that they’re not just because you’ve decided to consider it a bug is nonsense.
Look, I’m just going to leave one more link here and disengage: https://url.spec.whatwg.org/#concept-domain (but also see the definition of “origin” in that document, which clearly refutes your claim of sameness):
> The example.com and example.com. domains are not equivalent and typically treated as distinct.
You are arguing against facts that I have already clearly demonstrated. Get out Wireshark and test.
Once again, mistakes made by an application-layer program (or spec!) do not invalidate the facts of underlying layers.
The hostname will always resolve to the same IP. A search domain doesn't change that, it changes what hostname is resolved.
(BTW: hostnames have existed since long before whatwg or even the web. I'm not sure why you would think whatwg have the authoritative definition of hostname.)
Also, since you like specs, here you go: "every domain name ends with the null label of the root", implying that the domain `foo` is, in fact, canonically, the domain `foo.` - RFC1035, November 1987. (The RFCs contemplate search domains as well, and mention that the final dot might be used as a cue to the application/library whether or not to apply the search domains, but that's entirely an application/library decision and changes the effective hostname/FQDN.)
In short: I never said that browsers and servers don't in fact treat them differently, I said that's a bug. You can't say "well they do it that way and the spec they wrote says it" as reasoning for it.
When I said “almost always”, I was referring to search domains as the exception, I just didn’t think it worth clarifying (though I was amused by the fact that it’s the oft-broken-at-HTTP-and-above one that’s reliable at DNS).
Look, the difference is trivially demonstrated and eCa’s original claim trivially falsified: unless you’ve gone out of your way already, at https://news.ycombinator.com/ you’re logged in, at https://news.ycombinator.com./ you’re not logged in, because the hostname and thus origin is different, and also they’re not same-site, and thus cookies and such are not shared.
ai and www.ai might serve the same content, might have one redirect to the other, might serve different content: they’re different hostnames and different origins, they can do what they like and it’s no bug in anything. ai and ai. might serve the same content, might have one redirect to the other, might serve different content: they’re different hostnames and different origins, they can do what they like and it’s no bug in anything.