Closed Bug 247431 Opened 21 years ago Closed 19 years ago

An URL with a name from the hosts file, not resolvable from DNS, is failed, and may be handed to the search mechanism.

Categories

(Core :: Networking, defect)

1.7 Branch
x86
Windows 2000
defect
Not set
normal

Tracking

()

RESOLVED EXPIRED

People

(Reporter: nhi, Assigned: darin.moz)

References

()

Details

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040614 Firefox/0.9 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040614 Firefox/0.9 If you make a hosts file (c:\WINNT\system32\drivers\etc\hosts) entry for a name which won't be found on the internet, firefox apparently won't bother looking for it in the hosts file, and will try various search mechanisms for finding it. For instance, place "216.239.37.99 bogusbogus" in the hosts file (that address is a google.com address). You can ping it (ping bogusbogus), but if you go to the address field of firefox and try it, it'll try to go to find the address, then go to www.bogusbogus.com and finally fail. IE doesn't do this. In fact, if you use the "File|Open File" in firefox, it will successfully handle this situation. Originally I found this because I have to access a bugzilla database via an ssh tunnel, which I have to have hosts-file-named to bugzilla (127.0.0.1 bugzilla). When I tried to get to the tunnel (http://bugzilla:8888/) it sent me to _bugzilla.com_ because of the search mechanism. If I have the hosts file set to something that looks more like an address (127.0.0.1 bugzilla.company.com) then my link (http://bugzilla.company.com:8888/) will fail at DNS. I have a hosts file entry for host "bugzilla" (not _this_ bugzilla, but a different one) which resolves to 127.0.0.1, and I have a link which is http://bugzilla:8888/etcetc The 8888 port is a local ssh tunnel. I am on a satellite (starband) link with very high latency (600-700ms). When this link is given to the address box, or a link is taken via a bookmark, Firefox seems to try it briefly, and then gives up and goes to search (getting me to bugzilla.com). I tried using "File|Open File" menu, and handed it the link, and it opened it just fine; IE also opens it just fine (from the address bar). Clearly, it's a valid link; the criteria for failing an address bar/bookmark lookup is apparently not sufficient. This actually shows another, directly related bug: A link in a bookmark should probably NEVER go through the search mechanism - it should either work, or fail - I wouldn't google it. Note that the "bugzilla" has to be in the name for this to occur, as the remote site has more than one webserver apparently, and switches on the "bugzilla" name to get me to bugzilla. I tried this also with "bugzilla.tadpole.com" going to 127.0.0.1, with different results: I got a DNS name lookup failure. From a cmd window, however, I was able to ping bugzilla.tadpole.com, which tells me that firefox is not considering the hosts file. Reproducible: Always Steps to Reproduce: 1. make a hosts file entry with a valid IP address, like 216.239.37.99, and a name which won't be found on the web ("bogusbogus"). 2. ping the name to verify ("ping bogusbogus") 3. try to reach it via firefox by putting it in the address box ("http://bogusbogus") 4. Note failure. 5. Use File|Open File menu (or Ctrl+O) to open it. Note success. Actual Results: The address box entry failed to get to the right place (got DNS failure). The Open File got to the right place (google). Expected Results: The address box entry should try to resolve addresses using the hosts file in addition to DNS.
Sorry for the mess of description, as I my initial exploration was more complicated, and I'd already written that up, and didn't delete the rest of the epxlanation...... so if possible, just read the first four paragraphs of the description.
WFM. Make sure you close FF before you try to use the newly added name in the hosts file. I believe it is read when FF loads and it doesn't query it durning operation. I'm not positive, but that's been my experience. It doesn't work if you add a new entry while FF is still running, but it will work once you close FF and restart it. Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040614 Firefox/0.9
I get this bug too - very annoying. Definitely does not WFM! Has never worked for me. This behaviour used to happen for localhost address, but that seems to have been fixed. This would potentially break Firefox in a LAN environment with a local web server - the user would have to know the IP address to access it. Since this doesn't happen for IE I wonder which browser the average user would opt for. More infuriating is that even if I put http:// before the hostname, Firefox still goes to Google! A server not found message would be far preferable than getting sent to a commercial site! Perhaps in this, Firefox is too similar to IE!
There is surely another bug out there about valid host names being passed to the search mechanism. This may be a dupe of one of those. I don't believe I've ever experienced this bug with my hosts file setup. The steps described work fine for me on: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7) Gecko/20040803 Firefox/0.9.3
I access the internet through a proxy server and have certain sites in the local intranet, which I do not want to access over the proxy server (including some servers which do not have an entry in the DNS server and have entries only in the hosts file). Firefox does not look into the hosts file for the IP address unless the hosts or domains are mentioned in the 'No Proxy for' section of the Connection Settings. It goes to the proxy server directly and tries to resolve those hosts using the internet DNS without looking at the local hosts file. So, if I have an IP mask in the 'No Proxy for' section, and try to access one of the sites in that mask using the host name, which is present in the hosts file only, Firefox does not try to resolve it from the hosts file and goes directly to the internet. If, however I try to access those sites using the IP address or the 'No Proxy for' section contains host name or domain name filters for those hosts, Firefox does not go to the proxy and accesses the sites directly. I am using : Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3) Gecko/20041001 Firefox/0.10.1 on a Windows 2000 (SP-4) machine. Reproduceable : Always (from behind a proxy server - I do not have access to a machine with direct internet connection!) Steps to reproduce : 1. Make a hosts file entry for an IP address and a host name which will not be found on the internet. 2. Restart firefox and try to access the site using the host name, and firefox will go to the proxy server. 3. Make an entry of the host name in the 'No Proxy for' section and try to access the site, you will hit the site. I believe the problem reported by Nathaniel is a valid problem and should be looked into. The steps above might be a workaround to the actual problem which forces Firefox to look into the hosts file, which otherwise it would not.
Firefox does appear to read the host file, but not always in the right order (see explanation below). 1) Set a manual proxy via Tools->Options->Connection Settings...->Manual proxy configuration (try 212.42.175.155 port 80) 2) Add an entry to your windows host file that maps a local (intranet) site name to an IP address (e.g. YourLocalSite 192.168.1.1) 3) Try accessing YourLocalSite (which won't work. and may even access an online site with a similar name). 4) Add "192.168.1.1" to the Tools->Options->Connection Settings...->No proxy for entry. 5) Try accessing YourLocalSite (which won't work. and may even access an online site with a similar name). The problem seems to be that the "No proxy for entry" settings are resolved before the windows Host file is checked. This can be confirmed as follows: 6) Turn off the manual proxy (change it to "Direct Connection to Internet" on Tools->Options->Connection Settings). The local site will now be displayed correctly.
Assignee: firefox → darin
Component: General → Networking
Product: Firefox → Core
QA Contact: general → benc
Version: unspecified → 1.7 Branch
This is an automated message, with ID "auto-resolve01". This bug has had no comments for a long time. Statistically, we have found that bug reports that have not been confirmed by a second user after three months are highly unlikely to be the source of a fix to the code. While your input is very important to us, our resources are limited and so we are asking for your help in focussing our efforts. If you can still reproduce this problem in the latest version of the product (see below for how to obtain a copy) or, for feature requests, if it's not present in the latest version and you still believe we should implement it, please visit the URL of this bug (given at the top of this mail) and add a comment to that effect, giving more reproduction information if you have it. If it is not a problem any longer, you need take no action. If this bug is not changed in any way in the next two weeks, it will be automatically resolved. Thank you for your help in this matter. The latest beta releases can be obtained from: Firefox: http://www.mozilla.org/projects/firefox/ Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html Seamonkey: http://www.mozilla.org/projects/seamonkey/
This bug has been automatically resolved after a period of inactivity (see above comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Closed: 19 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.