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)
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.
Reporter | ||
Comment 1•21 years ago
|
||
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.
Comment 2•21 years ago
|
||
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!
Comment 4•20 years ago
|
||
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
Comment 5•20 years ago
|
||
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.
Updated•20 years ago
|
Assignee: firefox → darin
Component: General → Networking
Product: Firefox → Core
QA Contact: general → benc
Version: unspecified → 1.7 Branch
Comment 7•19 years ago
|
||
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/
Comment 8•19 years ago
|
||
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.
Description
•