I've had web browsers perform a web search for 'localhost', or even just redirect me to localhost.com. Annoying.
If you leave a trailing slash it will prevent this problem.
Internet Draft: Let 'localhost' be localhost
81–90 of 179 posts
Re: Internet Draft: Let 'localhost' be localhost
#82Earlier quoted context omitted.
Why?
Same-site scripting: http://seclists.org/bugtraq/2008/Jan/270
Interesting. Still, that requires the attacker to be already running a process on the victim's machine, even if with reduced privileges. Nowadays that's rare, since there's no reason not to give each user its own network namespace, at the very least.
Re: Internet Draft: Let 'localhost' be localhost
#83Re: Internet Draft: Let 'localhost' be localhost
#84First, the lack of confidence that "localhost" actually resolves to the loopback interface encourages application developers to hard-code IP addresses like "127.0.0.1" in order to obtain certainty regarding routing. This causes problems in the transition from IPv4 to IPv6 (see problem 8 in [draft-ietf-sunset4-gapanalysis]). That does remind me of the times I was dealing with weird connection issues in some critical s…
> and that breaks everything If you're on a POSIX system, I'd argue that this is a bug in the client. Typically, the client should call getaddrinfo(3); as part of that, the application would either specify directly that it's only interested in AF_INET results, or just filter out non-AF_INET results. (Further, if you support IPv6 in the client, and thus request such results from getaddrinfo, you should skip to the nex…
I agree about getaddrinfo(). Applications should have specified AF_INET to gethostbyname() and then when updating to getaddrinfo(), handle ipv6 correctly or skip it.
The IPv4-mapped IPv6 addresses thing is a terrible idea that ends up turned off everywhere it makes a difference. Like all of these "transition" ideas, it tries to help, but it just hurts by causing admins/ops/devs to just make sure ipv6 is off everywhere they run into it.
If all IPv6 was just opt-in everywhere, we wouldn't need all significant applications to detect and work-around broken ipv6 (in the local network, in the ISP, in the server, in the peer application). If IPv6 was only explicitly enabled, and fully consciously handled when it was, then practically everything would have opted into IPv6 years ago. As it is, things started getting IPv6 support around 2005/2006, and then disabling it around 2007/2008 because it was fake/broken ipv6 in too many places (windows teredo, 6in4, etc).
OS X had to disable IPv6 in one release and then re-enable after implementing happy-eyeballs in everything. Firefox had to do that. I know about these cases in particular, but I bet all significant network applications had to have a bunch of "detect broken IPv6" code added. Major websites had to disable IPv6 on their main domains (and sometimes added an "ipv6." subdomain). The reason was that some people had broken IPv6 and their computer would try to use it to access their site and fail (but other ipv4 only websites worked). Things are getting better now, but it was a 10 year set-back. So much time and effort could have been saved if people with good-intentions didn't add automagic transition technologies and just waited for IPv6 to be explicitly added on both ends.
Re: Internet Draft: Let 'localhost' be localhost
#85Re: Internet Draft: Let 'localhost' be localhost
#86[deleted]
Re: Internet Draft: Let 'localhost' be localhost
#87At least on the OS I use, which is more IPv6 ready than most, /etc/hosts solves this "uncertainty" problem.
I have found that failing to include a localhost entry in the HOSTS file can lead to some strange behavior.
If there are "computers" out there that have no /etc/hosts or deny the computer's owner access to it, then maybe it might be time for an Internet Draft from Joe User.
There should always be a mechanism for the user to override the internet DNS. And applications should continue to respect it.
Re: Internet Draft: Let 'localhost' be localhost
#88Sounds reasonable, but would probably break a ton of stuff. Does this provide enough benefits to outweigh the downsides?
Re: Internet Draft: Let 'localhost' be localhost
#89At least on the OS I use, which is more IPv6 ready than most, /etc/hosts solves this "uncertainty" problem. I have found that failing to include a localhost entry in the HOSTS file can lead to some strange behavior. If there are "computers" out there that have no /etc/hosts or deny the computer's owner access to it, then maybe it might be time for an Internet Draft from Joe User. There should always be a mechanism fo…
I remember in the late 90s running into a "mysterious" problem where www.hotmail.com would fail to load, but hotmail.com (without www.) worked just fine.
Spent the better part of a year just remembering to not type "www." until one day they made the domain redirect to the canonical name (breaking both).
After asking around a bit, someone showed me where the Windows equivalent of /etc/hosts was, and lo-and-behold, there was an outdated entry for www.hotmail.com there. Deleting the offending line fixed the problem.
Desktop computers are actually the odd one out in letting people manually override DNS -- if you want to fix the DNS for a phone or smart tv or thermostat or video game console, you need to configure DHCP and a resolver on a router in the middle.
Re: Internet Draft: Let 'localhost' be localhost
#90Earlier quoted context omitted.
> and that breaks everything If you're on a POSIX system, I'd argue that this is a bug in the client. Typically, the client should call getaddrinfo(3); as part of that, the application would either specify directly that it's only interested in AF_INET results, or just filter out non-AF_INET results. (Further, if you support IPv6 in the client, and thus request such results from getaddrinfo, you should skip to the nex…
Does it matter if it's a bug in the client? Make it work like expected. Especially when changing infrastructure like IPV4->IPV6 - don't break existing userbase code! (This is a fundamental precept of Linux development.)
There's only so much the kernel can do to protect userspace from itself. When you have an interface which returns an explicitly extensible data structure, you have to assume userspace is going to at least ignore extended data it does not understand. Otherwise you cannot have such interfaces at all.