Closed Bug 178123 Opened 22 years ago Closed 21 years ago

Internet Keywords: "localhost" goes to "www.localhost.net.au"

Categories

(Firefox :: General, defect)

Product:
Firefox
Component:
General
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED DUPLICATE of bug 184433

People

(Reporter: Bugzilla-alanjstrBugs, Unassigned)

References

(Depends on 1 open bug,
URL
)

Details

I have localhost mapped to 127.0.0.1, for obvious reasons.  Going to
http://localhost, or just typing in localhost in the URL bar, sends my machine
to google, which does the "I feel lucky" resulting in
http://www.localhost.net.au/.  

1) I think we need a preference for unknown sites.  IE gives a variety of
options: show results, go to most likely, and do not search from URL Bar.  

2) I think localhost should be exempted from that search

Mozilla returns "connection refused"
Not Phoenix

Confirming on 20021024 on WinXP
Component: Preferences → Networking
Product: Phoenix → Browser
Summary: Localhost feels lucky with google → "localhost" should not be treated as search criteria in URL bar
Version: unspecified → other
I can reproduce this problem in Win2K 20021104, but ONLY if I turn on Internet
Keywords, which is disabled by default.

In addition, I don't think that this is too much of a problem. Really, if
Internet Keywords are turned on, this is the correct behavior.

-M
Phoenix does not currently have a checkbox for this stuff, which was why I
originally put it as Phoenix.  What is the user_pref so I can manually disable that?

I still think localhost should be exempted, though.  Not even doing a
localhost:80 can connect me to my own machine.  I'd have to type in the IP.  I
have localhost mapped as 127.0.0.1 in my hosts file, but it does the keyword
thing without even trying to connect.
-> URL bar
Assignee: blaker → hewitt
Component: Networking → URL Bar
QA Contact: asa → claudius
Looks like a duplicate of bug 95390. Also see related bug 159742.

*** This bug has been marked as a duplicate of 95390 ***
Status: UNCONFIRMED → RESOLVED
Closed: 22 years ago
Resolution: --- → DUPLICATE
Status: RESOLVED → VERIFIED
REOPEN: Internet Keywords + "localhost" is going to get its own bug.
Status: VERIFIED → UNCONFIRMED
Resolution: DUPLICATE → ---
Summary: "localhost" should not be treated as search criteria in URL bar → Internet Keywords: "localhost" should not be search criteria in URL bar
Assignee: hewitt → location-bar
QA Contact: claudius → benc
-> NEW.

This is the original Phoenix|Firebird Internet Keyword/Localhost bug.

Please do not mark this bug as a duplicate to other bugs, the purpose is this
bug should stay open, and Firebird bugs can be duplicated to it, giving an
accurate account of how much this issue is affecting people.
Status: UNCONFIRMED → NEW
Depends on: 150025, 184433
Ever confirmed: true
Summary: Internet Keywords: "localhost" should not be search criteria in URL bar → Internet Keywords: "localhost" goes "www.localhost.net.au"
No longer depends on: 184433
Depends on: 184433
Summary: Internet Keywords: "localhost" goes "www.localhost.net.au" → Internet Keywords: "localhost" goes to "www.localhost.net.au"
Component: Location Bar → General
Product: Browser → Firebird
Version: Trunk → unspecified
*** Bug 185028 has been marked as a duplicate of this bug. ***
*** Bug 204845 has been marked as a duplicate of this bug. ***
*** Bug 206662 has been marked as a duplicate of this bug. ***
*** Bug 213204 has been marked as a duplicate of this bug. ***
*** Bug 229857 has been marked as a duplicate of this bug. ***
*** Bug 232200 has been marked as a duplicate of this bug. ***
For more information about this feature:
http://www.mozilla.org/docs/end-user/internet-keywords.html
If localhost is in your hosts file properly, but is still getting sent to a
keyword server, then it's an OS resolver problem.  localhost should not get
special treatment for the reasons that I explained in bug 213204 comment 6:

I don't think that Moz should do anything special for localhost.  Conventions
says that localhost should be 127.0.0.1, but there isn't any RFC that defines it
as such, AFAICT.  It's perfectly legal (although stupid) to assign an IP address
other than 127.0.0.1 for localhost (except for WAIS and FILE protocols, which
handle it specially.)

The solution is to add localhost to your hosts file (which Windows should have
done automatically.)
Jerry-

Can you give http://www.faqs.org/rfcs/rfc2606.html a read-through?
It's still the same as it was when I re-read it yesterday, and is totally
irrelevent to this bug.  As the title suggests, that RFC deals with "Reserved
Top Level DNS Names", not host names.  In fact, that RFC only says how the
.localhost TLD is traditionally used, but it's perfectly legal (although stupid)
to use it differently.

However, after doing another full text search of the RFCs for "localhost" (there
are only 17 results,) I did find that RFC 2396 updates RFC 1738 (which I had
originally cited.)  Section G.3. states that the "host" portion of a URL may be
a host of "localhost".  RFC 173 defines localhost as `the machine from which the
URL is being interpreted'.

Now, how to interpret `the machine from which the URL is being interpreted'. 
For most platforms, that would would be to just go to 127.0.0.1, but it may be
different on some.

Anyway, this is really not a keyword issue at all anymore, it's a resolver
issue.  We shouldn't be hitting the resolver at all for "localhost".  The
easiest approach would probably be to do a fakey lookup on startup that adds
localhost to the DNS cache with no expiration.
And if there is no server running on localhost, would it still throw it into IK?
 I mean if I just type "localhost" into the url bar and press enter.
OS: Windows 2000 → All
Hardware: PC → All
Not if the patch to bug 184433 ever gets checked in.
as far as I can tell, this should now be fixed with the checkin for  bug 184433
IMHO, anything beginning with http:// (or any other protocol, for that matter)
in the address bar should not be sent to Google or any other search engine 
for lookup.

If we have a google bar, I'm not sure why we need to do google searches
from the address bar anyway.  It's probably more to keep the two separate, 
or perhaps only send entries that could not possibly be a valid address
to google. Just because an address is unreachable at the moment is a
very bad reason to consult a search engine, which could, for example,
lead someone to a bogus site crafted to impersonate the real site.  
No, please!  Don't even consider allowing a real URL to be interpreted 
as a web keyword search jumping directly to the "most likely" site!


IMHO, anything beginning with http:// (or any other protocol, for that matter)
in the address bar should not be sent to Google or any other search engine 
for lookup.

If we have a google bar, I'm not sure why we need to do google searches
from the address bar anyway.  It's probably more to keep the two separate, 
or perhaps only send entries that could not possibly be a valid address
to google. Just because an address is unreachable at the moment is a
very bad reason to consult a search engine, which could, for example,
lead someone to a bogus site crafted to impersonate the real site.  
No, please!  Don't even consider allowing a real URL to be interpreted 
as a web keyword search jumping directly to the "most likely" site!

(In reply to comment #22)
> IMHO, anything beginning with http:// (or any other protocol, for that matter)
> in the address bar should not be sent to Google or any other search engine 
> for lookup.

It's impossible to tell if the user typed a protocol into the URLBar by the time
this gets invoked.  The interfaces are frozen, so it's not going to change in
the near future.  We just have to wait until nsIURI gets revved (if ever, and it
doesn't make sense to rev it to accommadate a feature that can be turned off.)

> If we have a google bar, I'm not sure why we need to do google searches
> from the address bar anyway.  It's probably more to keep the two separate, 
> or perhaps only send entries that could not possibly be a valid address
> to google. Just because an address is unreachable at the moment is a
> very bad reason to consult a search engine, which could, for example,
> lead someone to a bogus site crafted to impersonate the real site.  
> No, please!  Don't even consider allowing a real URL to be interpreted 
> as a web keyword search jumping directly to the "most likely" site!

It's not a google search when it's entered into the URLBar.  It's a keyword
search (which happens to do a google "I'm Feeling Lucky" search by default, but
can be changed.)  If you don't want that behavior, simply turn of keyword
searches.  I'm working on getting it into the GUI (along with some other keyword
changes, see bug 232720.)
The is problem, as originally described, was fixed by bug 184433.  

(In reply to comment #17)
> Anyway, this is really not a keyword issue at all anymore, it's a resolver
> issue.  We shouldn't be hitting the resolver at all for "localhost".  The
> easiest approach would probably be to do a fakey lookup on startup that adds
> localhost to the DNS cache with no expiration.

So is that the approach this bug (or some new bug) should take?  
(In reply to comment #24)
> The is problem, as originally described, was fixed by bug 184433.  
> 
> (In reply to comment #17)
> > Anyway, this is really not a keyword issue at all anymore, it's a resolver
> > issue.  We shouldn't be hitting the resolver at all for "localhost".  The
> > easiest approach would probably be to do a fakey lookup on startup that adds
> > localhost to the DNS cache with no expiration.
> 
> So is that the approach this bug (or some new bug) should take?  

IMHO this bug should be closed as a dup of bug 184433, and a new bug should be
opened to add localhost to the DNS cache.
Bug 233002 submitted.  Duped to 184433 per jtalkington

*** This bug has been marked as a duplicate of 184433 ***
Status: NEW → RESOLVED
Closed: 22 years ago → 21 years ago
Resolution: --- → DUPLICATE
Ted, re #21 & 22: that is bug 95390.

Jerry, re #23, URL bar input and links do go to the same URL parser, but some
features  (like Internet Keywords and Domain Guessing) are limited to URL bar input.

Verified as a dupe, even though it really should have stayed a depends (see
comment #7).
Status: RESOLVED → VERIFIED
No longer depends on: 184433
(In reply to comment #27)
> Jerry, re #23, URL bar input and links do go to the same URL parser, but some
> features  (like Internet Keywords and Domain Guessing) are limited to URL bar
>input.

Nope.  Internet keywords will be invoked if you click on a link that points to a
non-existant host.  Try this out: http://laskjdapoweruiosdf/, it will bring up a
keyword search.
Jerry, thanks for the correction. Yeah, I realized that was bug 184814 after I
posted here.
*** Bug 236850 has been marked as a duplicate of this bug. ***
*** Bug 229229 has been marked as a duplicate of this bug. ***
You need to log in before you can comment on or make changes to this bug.