Split from bug 178123, this bug is to add a non-expiring localhost entry to the DNS cache to prevent it from going to the wrong place if not defined in the hosts file.

This has nothing to do with docshell.

Sorry. I thought I saw one of the DNS bugs pointing there.

so, we could also make docshell's URI fixup code never try to fixup localhost. i think that would be preferred since the bug the reporter is trying to get us to work around could also be caused if there is no HTTP server on localhost, which is i think the more common case. if you agree, then this bug should be reassigned to docshell and its summary should be changed accordingly.

Why? That is, if I type "localhost" in the URL bar, why would we do anything differently from the case when I type "foo" in the URL bar? Perhaps a clear explanation of the problem we are trying to solve is in order? Bug 178123 has a lot of confused comments, people not understanding what's going on, etc. Now that bug 184433 is fixed, "localhost" will only trigger fixup if it in fact does not resolve (contrary to comment 3). Is that the problem we are trying to solve? Why are we trying to solve it? I'm also very strongly opposed to doing a "fake lookup" for localhost. If I have localhost aliased to localhost.localdomain.com in my aliases file, I had damn better get the right things loading if I type "localhost" in the URL bar.

Although I suggested that this bug be filed, I'm also opposed to doing anything special with "localhost". Unfortunately, RFC 2396, section G.3 is sufficiently vague as warrant an examination. RFC 1738 says that a URL host should be a fully qualified domain name. RFC 2396 says: The URL host was defined as a fully-qualified domain name. However, many URLs are used without fully-qualified domain names (in contexts for which the full qualification is not necessary), without any host (as in some file URLs), or with a host of "localhost". Going back to RFC 1738, "localhost" is interpreted as `the machine from which the URL is being interpreted'. It's a pretty craptacular addendum, but it's there none the less. So, if a URL is entered with the host of "localhost", we should always try to go back to the machine that we are running on.

Has anyone tried assigning localhost to something other than 127.0.0.1? I updated my hosts file on win2k to point localhost to 216.109.118.77. So far I only get a connection failed error in Firebird and a keyword search in IE6.

(In reply to comment #4) > Why? That is, if I type "localhost" in the URL bar, why would we do anything > differently from the case when I type "foo" in the URL bar? i'm only proposing that we do something different in the error case. (i.e., i'm proposing that we not try to do URL fixup on "localhost".) why "localhost" ... b/c 1) URL fixup is a heuristic we control and 2) localhost is very unlikely to correspond to www.localhost.com or to better resolved by google's "i'm feeling lucky" service. > Perhaps a clear explanation of the problem we are trying to solve is in order? > Bug 178123 has a lot of confused comments, people not understanding what's going > on, etc. Now that bug 184433 is fixed, "localhost" will only trigger fixup if > it in fact does not resolve (contrary to comment 3). Is that the problem we are > trying to solve? Why are we trying to solve it? well, this does enlighten me quite a bit. i forgot that we made that change (geesh... and i even reviewed that patch)! > I'm also very strongly opposed to doing a "fake lookup" for localhost. If I > have localhost aliased to localhost.localdomain.com in my aliases file, I had > damn better get the right things loading if I type "localhost" in the URL bar. i agree.. we should not do a fake lookup for localhost. i think you would agree that disabling URL fixup does not constitute a fake lookup. sure, we would be making an assumption about localhost, but that assumption seems reasonable to me. afterall, localhost has a very ubiquitous meaning. i guess when it comes down to it, i could go either way. realistically, we are fine as is. there really isn't that much left to do. disabling URL fixup on localhost would be a small change with little side-effect. afterall, how common is it for an OS to not know how to resolve localhost ;-) IMO this bug should either be resolved as WONTFIX or FIXED with that tweak to URL fixup to exclude localhost.

clearly, it does not make sense to pre-populate the DNS cache with the value for localhost since we cannot assume that localhost maps to 127.0.0.1.

Ah, ok. Yeah, I have no problems with skipping UIR fixup on no-such-host errors for the "localhost" host.

Actually, the change would need to go into nsWebShell::EndPageLoad. It would be pretty cinchy to add a check for "localhost". I can make a patch here, or do it as part of bug 232720.

OK, let's do that. Back to docshell, since we're not talking about the DNS cache anymore. Jerry, either way that works for you better.

alanjstr: you are the reporter, so I'm inclined to let you be the final arbiter of this bug. If you wanted to propose hard coding DNS cache, we can't do that, b/c localhost is not strictly defined as 127.0.0.1, it can actually be any loopback address, which is on the 127.0.0.0/255.0.0.0 network. So this would be a wontfix, as Darin has said. If you are basically saying: we never should have let features that interpret user input (like domain guessing and internet keywords) touch something as explicit in meaning as "localhost", then this is probably a dupe of bug 150025. Now that bug 184433 was fixed, that should be the root cause of bug 178123, but there were so many server side hacks to netscape's internet keywords over time + not so great bug triage, that I'm still concerned there is one or two more wierdo behaviors that will show up. That is why, although bug 150025 is likely not to be a problem anymore, it is still worth leaving open, and possibly a good design feature give localhost special exclusion from these features in the future. We had a similar problem w/ whether or not localhost should be proxy-able by default. bz's apparent indignation in #4 is pretty much what I have been trying to define as a problem, for some time now.

*** This bug has been marked as a duplicate of 150025 ***

V