Setting an IP address in the No Proxy field does not work for a name that resolves to that IP address. Meaning I put 127.0.0.1 in the No Proxy field. I then do http://localhost/ which resolves to 127.0.0.1 via the hosts file. It will attempt to go through the proxy for this address even though it resolves to 127.0.0.1. This is somewhat of a pain because I was trying to use a hosts file which contains a list of advertising sites, etc. and has them point to 127.0.0.1. Unfortunately that doesn't work with the current setup. It would be nice if the DNS call occurred before it called the proxy server or maybe a check box. The closest bug that I found to this was bug 80918
CONRIFMED/helpwanted: I've seen this while working on a couple No Proxy issues. Basically, we do a string compare. Can someone check if this worked in Comm 4? If so, you can keyword 4xp
If you put the name in the no proxy field, (items are seperated by commas I believe), it should work as expected. I just tested with: "127.0.0.1,localhost,.fibrespeed.net" and the proxy wasn't used for: http://127.0.0.1/test.html http://localhost/test.html http://www.fibrespeed.net/ Just FYI; is this still a bug then?
The more general point is that people want to be able to put an IP address and NOT the name, but have the names be blocked by IP. For example, looking at some DNS entries for mozilla.org: mozilla% nslookup www.mozilla.org Server: regress.nscp.aoltw.net Address: 10.169.115.222 Non-authoritative answer: Name: gila.mozilla.org Address: 188.8.131.52 Aliases: www.mozilla.org If this worked as requested, you could put "184.108.40.206" and block both "gila.mozilla.org" and "www.mozilla.org". The feature has more general uses than just localhost, which I agree has a simple workaround since you generally assume that localhost==127.0.0.1.
I'd call it a *feature* that the browser doesn't resolve names when using a proxy. My site has a Squid proxy configured to work transparently but I still prefer to configure Mozilla to use it explicitly in order to avoid DNS lookups in my machine. Squid would have to perform the lookups anyway. This speeds up my browsing significantly. I think that if you really want to avoid the proxy for a server accessed both by name and by address it's easy enough to specify both on the "no proxy for" line.
That was true until darin added better support for IP address ranges. Now people who want do do things like block their local subnet, can do so (as long as the URL is using an IP address). What people probably want (based on many sample PAC files we see) is that they want the network-level "no proxy" for all URLs, including the more common URLs w/ domain names.
*** Bug 252815 has been marked as a duplicate of this bug. ***
I think we shouldn't do a client-side lookup, unless there's an ipaddress or ipaddress-range in the 'no proxy for' field. A DNS-lookup both in the client and in the proxy should be avoided.
RECOMMEND: WONTFIX. After thinking about this on and off for several years, it finally occurred to me, thanks to Jo's last comment, that implementing this would basically inflict the IsInNet() latency problems PAC users enjoy. As I've done cleanup on this feature, I've found that this is one of the most impossible features of proxy to make robust. Unless IE does this, there is no reason to add this, people should use PAC for what they want here.
In fact, IE does do this, quite nicely. Note that you can easily reproduce by editing the hosts file to add the server you want. I, for instance, use a web server every day that is in our local network, but not accessible from outside the network (work related, ie.). I have added a hostname to the hosts file for the IP address, so that everything works nicely within the website itself. When I enter the hostname that I defined in hosts in Firefox, I cannot get to the website (as it goes through the proxy). If I enter the IP address, it gets to the website (but the website requires that the name is there, or none of the scripts work properly). In IE, on the other hand, entering the name works perfectly.
13 years ago
Ryan: I don't think you are talking about the same thing. This bug says: "if I put an IP address in 'no proxy', then URLs that resolve hostnames that connect to that IP address should not use the proxy."
In fact, I believe this would all relate to the same thing. As many ways as you put it, anything in the proxy setup doesn't check the IP address that a hostname resolves to. Even if it's the 'no proxy', or the proxy itself.
*** Bug 266251 has been marked as a duplicate of this bug. ***
*** Bug 284270 has been marked as a duplicate of this bug. ***
This and 72444 are basically the show stoppers for my company from using Firefox company wide. We've finally ousted all the MS JVM web apps, gotten all the intranets W3C stardard HTML/CSS and got rid of all the active x requirements and no vbscripts. All we need is an easy way to prevent Firefox from trying to resolve internal IPs via the proxy without having adding 25 different subnets and more than 25 different host names.
Have you considered using a Proxy Auto Config file? It gives you the ability to compare the resolved IP against a set of do not proxy IPs.
I see this as an issue that needs resolved, whether one considers it a bug or feature is besides the point. Consider this setup: Connected to a private network (192.168.30.0/24) Connected to a SSH server (a public IP outside the private network) for a SOCKS5 proxy All DNS lookups are handled by a private DNS server (192.168.30.5) (ie DNS is -not- resolved over the proxy) So, it seems like a good general solution for this setup is to configure any traffic to the private network, to not go over the proxy. So, in firefox/thunderbird one might set the following: network.proxy.no_proxies_on = 127.0.0.0/8, 192.168.30.0/24 Now, as the original bug report states, this does not work, unless you are accessing the servers by IP and not by Domain Name. In my above setup description, it would be unrealistic and pointless to try to figure out what the private DNS server is resolving to private IPs and to external IPs. In fact this completely removes any point of having DNS in the first place. If one has to start caring about how a domain name resolves simply to get some software to work, it seems the software has problems. To have to manually enter every possible domain name on a private network is out of line.
I agree with 19 and also see this as an issue that needs resolving. We are planning to deploy firefox in our organisation where we host many sites on our network range that do not end in our DNS suffix (therefore we cannot use .blah.com in the 'no proxy for' declaration). We do however have internal people on our network who wish or need to access these sites directly, rather than through a proxy. It would be great if we could just stick in a netmask range, and any hostnames that resolved in this range would not use a proxy. Our only other option is to add a specific 'no proxy for' for each of these hostnames and they are numerous and varied. It also does not future proof us should we add more hosts on our ip range that need access without a proxy. So, as I see it, the no proxy code should try and resolve the hostname first, then if it resolves check what it resolves to in the no proxy for list, and if it doesn't resolve then check the hostname as normal.
(In reply to comment #20) > We are planning to deploy firefox in our organisation where we host many sites > on our network range that do not end in our DNS suffix (therefore we cannot use > .blah.com in the 'no proxy for' declaration). We do however have internal > people on our network who wish or need to access these sites directly, rather > than through a proxy. Just make a PAC file, that's much easier. And it can be centrally maintained. It's even backwards compatible with other browsers, even with Internet Explorer. <http://www.mozilla.org/catalog/end-user/customizing/enduserPAC.html>
documentation : http://wp.netscape.com/eng/mozilla/2.0/relnotes/demo/proxy-live.html Note that you can also install using WPAD, (see <http://en.wikipedia.org/wiki/Web_Proxy_Autodiscovery_Protocol>), in which case it can be automatically discovered by the browser.
(In reply to comment #21) > Just make a PAC file, that's much easier. And it can be centrally maintained. > It's even backwards compatible with other browsers, even with Internet > Explorer. The problem is, the usual corporate standard is IE. It works without a PAC file, so noone is going to bother creating one for the misguided Firefox users. Other point: Being afraid of the slow DNS lookups is usually not justified, as if we have a proxy and an intranet, we also have an internal DNS server with a cache. It will not be slow. Besides, working somewhat slowly is a lot better than not working, however fast. But why not have the user decide? Add a pref, if they want to, they can turn on DNS lookup before the no-proxy-list match, if they want to, they can leave it off.
I would be with Sebastian Clarke's point of view (comment #20). If you ask me that's somewhat of a showstopper for Firefox users in many corporate network environments (such as where I work). I think FF is underperforming here, forcing me to make bookmarks containing the servers' IP addresses so I can access them quickly :( https://support.mozilla.com/de/questions/784031 It's just not feasible the way it is.
In my corporation, I have more than 120,000 stations with Mozilla Firefox and this problem causes a large negative impact on the adoption of free software solution. In 2009, Chris Hoffmann was here and talked to him about it until today but the problem was not solved. This is making me into a very complicated situation.
To add to Ryan Adler's comment (#11): The way IE does this has to do with the "Bypass proxy server for local addresses" option. If this is enabled, and you enter an address with no periods (hostname-only), it assumes the host is on the local domain and will try to reach it directly, bypassing the proxy. For example, if my computer is on domain "somewhere.lan" and a host "somehost.somewhere.lan" exists, then if I type in the address field "somehost" it will try to resolve it as "somehost.somewhere.lan" and go directly to it. If you uncheck this option, you will notice that it will send all hostname-only requests to the proxy -- like FF. I agree that this is needed in FF. This is not a bug; it's a long overdue feature request and in a corporate environment is just unacceptable. You can't seriously pretend that admins will add tens of hostnames to a PAC file... I dont see any disadvantages in adding this. Oh, and you won't get dual DNS requests if FF just chooses to stop trying if it cant resolve locally.
Abey Marquez, I agree with you! When we have this problem solved?
(In reply to comment #26) > The way IE does this has to do with the "Bypass proxy server for local > addresses" option. If this is enabled, and you enter an address with no periods > (hostname-only), it assumes the host is on the local domain and will try to > reach it directly, bypassing the proxy. > You can't > seriously pretend that admins will add tens of hostnames to a PAC file... Admins can easily test the existence of periods by using RegExp in the PAC file. Why such a long list is required?
In my opinion this is not really a question of "long PAC file" or "short PAC file" but rather a question of needing to have one at all, along with a server to host it. For instance, if I'd suggest to my CIO that we use Firefox at the company I work at, I'd have a hard time explaining why we need another virtual server with virtual hardware and OS and anti virus licences to be paid, alongside to the costs of administration time for all that and to keep the PAC file up-to-date, when this is not necessary for IE. Hence, IE it is and will be until this gets fixed with FF, it's as simple as that. (Yes, there are open source solutions to that, yes, we could host the PAC alongside on another server, but we have a policy to use Microsoft Server products and need to ensure redundancy and all that, and I'm not in the position to suggest a major strategy change.) Also, please think of the smaller enterprises that don't really have an IT department but rather just a utility man who handles all "computer-related" tasks and who has limited knowledge and maybe does not even know what regular expressions are and how to write them. Why not be nice and move a boulder out of their way by implementing this feature? For the guys having concerns about the speeds of resolving domain names: I think it would be relatively easy to regex-test whether the proxy exclusion text field contains IPv4 or IPv6 entries. As long as it doesn't, there is no need to resolve domain names and in that case the behavior can stay the way it is now in FF4 and before.
IE can also use a PAC file, and it often makes a lot of sense to use one, as it makes it much easier to edit a central location. In my company it's a file of 400 lines long, and it's often updated several times per day.
Jeez... this is like a linux vs windows argument. If you really want to do regexes and keep your pac files and use the pythagoras theorem in order to bypass a proxy go ahead. But at least give the users the option! Make it as easy or as difficult as the user wants it to be. That's true flexibility. Until FF doesnt appeal to the novice network admin it will just remain a curious novelty in the corporate environment. The way it is now, you have to edit the no-proxy box extensively, have programming experience (regex), or need to maintain an additional file (pac) in order to have basic functionality that IE (and inherently Chrome) gives us by default and has been doing so for years. Cmon ppl vote for this!
@ Patrick McManus [:mcmanus] Would you please provide some info about the reason for the WONTFIX? Thanks.
proxies doing the dns resolution, instead of the client, is something people rely on as a privacy feature. This can be done in PAC if need be.