Don't do URI fixup on localhost

VERIFIED DUPLICATE of bug 150025

Status

()

VERIFIED DUPLICATE of bug 150025
15 years ago
15 years ago

People

(Reporter: Bugzilla-alanjstrBugs, Assigned: adamlock)

Tracking

(Depends on: 1 bug)

Trunk
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

(Reporter)

Description

15 years ago
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.
Assignee: adamlock → darin
Component: Embedding: Docshell → Networking
QA Contact: adamlock → benc
(Reporter)

Comment 2

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

Comment 3

15 years ago
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.

Comment 5

15 years ago
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.
(Reporter)

Comment 6

15 years ago
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.

Comment 7

15 years ago
(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.

Comment 8

15 years ago
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.

Comment 10

15 years ago
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.
Assignee: darin → adamlock
Component: Networking → Embedding: Docshell
Depends on: 232720
QA Contact: benc → adamlock
Summary: add localhost to the DNS cache → Don't do URI fixup on localhost

Comment 12

15 years ago
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.
(Reporter)

Comment 13

15 years ago

*** This bug has been marked as a duplicate of 150025 ***
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → DUPLICATE

Comment 14

15 years ago
V
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.