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

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

Looks like a duplicate of bug 95390. Also see related bug 159742. *** This bug has been marked as a duplicate of 95390 ***

REOPEN: Internet Keywords + "localhost" is going to get its own bug.

-> 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.

*** 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.

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 ***

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).

(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. ***