3 ms·

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

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

hjV9H2bWu4ZhXPy 4y ago
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.
- riffic 4y ago
  yeah I'd listen to the IETF here vs the WHATWG. lol what a silly argument to get into.

hjV9H2bWu4ZhXPy 4y ago

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.

riffic 4y ago
yeah I'd listen to the IETF here vs the WHATWG. lol what a silly argument to get into.