On Aug 2, 2017, at 9:02 AM, Richard Barnes <r...@ipv.sx> wrote: > But of course having IP addresses in URLs is both a PITA for developers and > an anti-pattern more generally.
While true, I would argue that this is actually a problem. E.g., I actually literally cannot surf to a link-local URL without having a DNS record for it, because http://[ <http://%5Bfe80::1806:ec37:3d5f:9580%25en0%5D/>fe80::1806:ec37:3d5f:9580%en0]/ <http://%5Bfe80::1806:ec37:3d5f:9580%25en0%5D/> has an interface identifier in it, and modern browsers consider this an anti-pattern, I guess. And you don't want to put link-local addresses in DNS, even if it made sense to do so, so what is one to do? I'm not convinced that this anti-pattern is the wrong anti-pattern, but here we have two examples of it being problematic, in the least. > If "localhost" were properly defined to be loopback, then applications could > just hard-wire resolution, and not depend on the good graces of the platform > resolver. As, for example, Firefox does with ".onion" today: Right. But there was actually a long discussion on why that's problematic when we were doing the .onion RFC. The reason is that one can't count on any particular piece of application software correctly interpreting the rightmost label. We can write RFCs encouraging it, but if I am writing a URL into a piece of HTML, I have no idea whether the thing that interprets the HTML will or will not do the right thing. We just accept that as a risk with .onion because we don't have a better option, but for localhost we definitely do have a better option. That's all I'm saying.
_______________________________________________ DNSOP mailing list DNSOP@ietf.org https://www.ietf.org/mailman/listinfo/dnsop
