72444 - Proxy: "bypass proxy server for local addresses" (IE pref)

Status: RESOLVED FIXED

(Core :: Networking, enhancement)

Description

[Anatoly Kochergin]

There should be a checkbox or something like that in proxy settings dialog to
enable/disable proxy for intranet, like in IE.

Comment 1

[Keyser Sose]

Marking NEW.

Comment 2

[[e-mail]]

What's your definition of "the intranet?"

You can mark a list of domains as not handled by proxies already.

mark as wontfix?

Comment 3

[Anatoly Kochergin]

I have ~200 computers in local network. Each of them have http server. 
I wont to be able to access this servers by my browser without proxy.
So I have to add all ~200 IP's into ignore list?
MSIE do this by setting only one checkbox.

Comment 4

[[e-mail]]

I'm still not clear on the actual technical definition of what is the 
"intranet."

What you are asking for sounds like "all addresses within my subnet". That would 
probably be easy to do, but not meaningful to most customers.

I did some more looking at Microsoft's help description of the IE feature, and 
the lack of clarity was dizzying. The closest I could get was:

Local intranet zone: This zone typically contains any addresses that don't 
require a proxy server, as defined by the system administrator. These include 
sites specified on the Connections tab, network paths (such as \\server\share), 
and local intranet sites (typically addresses that don't contain periods, such 
as http://internal). You can also add sites to this zone. The default security 
level for the Local intranet zone is Medium. 

I have some MSCE materials and will look there to see if they can shed more 
light on what this feature actually means.

Comment 5

[benc]

mass move, v2.
qa to me.

Comment 6

[basic]

depends on bug 89928 ?

Comment 7

[Chase Tingley]

Actually I can think of a couple other ways around this.
If "No proxy for" supported ip addreess wildcards (bug 80918), that could be
used here.

Alternately, Anatoly could make himself a dummy PAC that used isInNet to do the
same thing.  However, this is also broken at the moment (bug 79057).

Another PAC approach might use isPlainHostName and/or dnsDomainIs to select the
intranet machines.  This would require them all to have names like
http://intranet or to fall within a particular set of domain names, though.

Comment 8

[benc]

The larger, feature-spec problem is that Microsoft hasn't really documented WHAT
is in their "Intranet" zone.

I looked at this further, and there is an additional set of settings I didn't se
the first time:

"Local intranet zone

Use the settings below to define which Web sites are included in the Local
Intranet zone. (note: inconsistent capitalization is theirs, not mine...)

[x] Include all local (intranet) sites not listed in other zones
[x] Include all sites that bypass the proxy server
[x] Include all network paths (UNCs).

This is another example of how PAC may end up serving as our generic "network
access" API, because we could probably create some UI that auto-generates a PAC
  file to conform to these settings.

Possibly another reason we need bug 89928.

Comment 9

[Daniel Mario Vega (Restore MNG Support --> #18574)]

I think what IE does when you select "Bypass proxy server for (local) intranet
address", is only to check if the server name in the URL has any dot in it. If
it has no dot it assumes it's a server on the intranet.  I think this check is
easy to implement and is also usefull

Comment 10

[benc]

I have updated the summary so that it matches the actual text of the feature in IE.

Daniel, based on the documentation, I think the feature is more complicated than
that.

This is an area where we need some clear-cut documentation (preferablly from
Microsoft). I have found them hard to reach, so another solution would be for
someone to write a test suite that shows what is proxied/not proxied, for all
combinations.

Comment 11

[basic]

these might be helpful:
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q303650
http://support.microsoft.com/default.aspx?scid=kb;EN-US;q262981

Comment 12

[benc]

baisc: nice find. I have to bend my mind to understand Microsoft-netisms, but it
certainly helps.

Comment 13

[benw]

i agree with comment #9 - all this pref needs to do is bypass proxy if there is
no "." in the entered url. that would certainly cover the functionality i need.

Comment 14

[Alex Haan]

I'm at a LAN-party at the moment.
We use a proxy to connect to the internet.
At the local intRAnet are a lot of computers with ftp-servers, etc.
This means a lot of ip-numbers or a lot of computernames.
These can't be entered all. And as far as I know wildcarts can't be used to add
a certain domain to the exclude list.

Checking for '.'-s in de URL won't work, because I also want to enter ip-numbers
as URLS.

(If tried PAC-files but they don't seem to work, yet)

Comment 15

[benc]

Please file a new bug for your .PAC problem and attach the file.

Comment 16

[Doug Turner (:dougt)]

moving neeti's futured bugs for triaging.

Comment 17

[David P James]

*** Bug 174102 has been marked as a duplicate of this bug. ***

Comment 18

[benc]

*** Bug 172228 has been marked as a duplicate of this bug. ***

Comment 19

[rkc]

I too would like to see Moz ignore the proxy for intranet accesses (defined by
the ".something" component).

Our situation: we have a local, non-proxied server x.something that includes a
page with accesses to other local addresses, all of which take the form
"http://y" (no ".something").  When configured properly, Moz will allow access
to x.something (not through the proxy), but selecting the "http://y" entry
attempts to go through the proxy, which naturally fails.

I believe that cuing on the "." would be sufficient for my aims.

Split this bug?

Comment 20

[benc]

I think there are other no-proxy bugs that cover what you are suggesting.

Comment 21

[3ryon 5utherland]

My guess is that the distinction that MS uses for "local addresses" is if the
name is a NetBIOS name (generally resolved by WINS) instead of a DNS name (ie.
without a '.').  

In my case the proxy attempts to resolve the NetBIOS name and fails...thus I
can't connect.  This is a pretty big issue for users inside a proxy where the
internal webservers are referenced by NetBIOS names....and the only reason I
have to keep IE around.

Comment 22

[benc]

-> reset to defaults for triage.

Mozilla does use what I believe is called WINS resolution if NetBios is in use,
I know this because one of my test cases assumes "mozilla.mcom.com" does not
exist, and someone has registered "MOZILLA" as a SMB host.

So my test case fails, but only on the Windows systems I have.

I have a pile of Windows networking books that I have never read, so I can do
more research on this if we decide to fix this bug.

Comment 23

[Doug Turner (:dougt)]

reassigning to darin.

Comment 24

[Craig Dickinson]

Agreed.  I work at an AF Base and we are implementing a Global Portal, which
requires bypassing a proxy server for local access.  When I attempt to connect
to this portal using Mozilla, I get the following error message:

HTTP 401.2 - Unauthorized: Logon failed due to server configuration
Internet Information Services

Comment 25

[Darin Fisher]

craig: sounds to me like you are probably getting seeing bug 23679.  mozilla
does not yet support Microsoft's proprietary authentication scheme.

Comment 26

[Craig Dickinson]

Will that be changed in the future?  Is there any plans to adopt MS's
authentication scheme?

Comment 27

[Darin Fisher]

Craig: yes (see bug 23679 for details)

Comment 28

[peter_coussement]

I need this "bypass proxy server for local addresses"  feature too. At work a
lot of the compaq servers i work with have a remote inside board. To work with
it i can fill the network name. But if i do this in Mozilla 1.3 release it
brings me to the http gate server and tries to search the server outside our lan.

Comment 29

[benc]

This bug still lacks a clear, specification-quality description of what would be
bypassed if you selected it.

However, I am getting the sense that there are a growing number of corporate
users  that are interested in using Mozilla, and cannot, probably because they
are suffering from a combination of proxy-only connectivity + links that do not
have FQDNs. The proxy-only aspect I know is true from being the former Netscape
Proxy Server support champion at Netscape. The second aspect I know because we
also have a lot of people that still do not put FQDN's in their links, and I
would imagine this is typical at most companies.

That being said, I think that we need to address this problem area, so I'm
marking this as +clean-report, so that it will get targeted by engineering. 

If we cannot figure out what would be the exact IE behavior to emulate, we
should at least fix bug 

Comment 30

[benc]

...fix bug 91587, which would probably get us most of the behavior people are
asking for. After that people can file bugs on the other MS behaviors nobody
seems to be able to figure out.

Comment 31

[Scott Valler]

We use a SideWinder 5.2.1 Firewall/Proxy and I would like to have the "intranet"
defined as the local subnet, unless there is a better solution.  We have several
domains running in-house and the local machines local domain may not match the
domain of the host we are trying to reach.  All hosts are on the same subnet for
this example.

Also, can we put in filters such as:
10.*
10.1.*
10.2.4.*
10.4.*:8080
10.1.2.3:1024
www.fred.com:4321
*.fred.com
*.fred.com:4357

Those are the types of filters we use to bypass our proxy for certain sites/port
combinations and for test networks that are local but not on the same subnet
when we test with IE 6.

Comment 32

[Robert Accettura [:raccettura]]

*** Bug 235005 has been marked as a duplicate of this bug. ***

Comment 33

[Carlos Rodrigues]

I would like to request this too. We have a lot of switches and some servers
here, and to access them with Firefox (in this case) one needs to turn off the
proxy. A "bypass proxy for local addresses" option would be really useful (local
addresses being names that resolve to an IP address matching the machine's
netaddress/netmask).

Comment 34

[Jared McAteer]

When "Bypass Proxy for Local addresses" (or whatever) is selected do the following:

- If local subnet give local dns priority, if fails try proxy, if fails google
search.
- If not local subnet but on the "reserved for private use" IP ranges give local
dns priority, if fails try proxy, if failes try google.
- If not local subnet and not reserved for private use give proxy priority, if
fails try local dns, if fails try google.

Reserved for Private use IP ranges:
Class	Networks
A	10.0.0.0 through 10.255.255.255
B	172.16.0.0 through 172.31.0.0
C	192.168.0.0 through 192.168.255.0

Also I found an article that details MSIE's behavior:

The 'Bypass proxy server for local requests' option is available on the 'LAN
Settings' window (from Internet Explorer menu, go Tools -> Internet Options ->
Connections -> LAN Settings). This means that requests for servers on your local
subnet are sent directly to that machine rather than to the proxy server. 

There are two gotchas which can mean that local requests get sent to the proxy
server even though the 'Bypass proxy server for local requests' option is ticked: 

Microsoft Internet Explorer works on the basis that if a URL has a dot in it,
it's not local (see Microsoft support article <a
href="http://support.microsoft.com/kb/q262981/">262981</a> for details and
workarounds). This means that local addresses such as http://192.168.168.57:8082
or http://my.domain.computername:8082 are treated as non-local, and so are sent
off to the proxy server regardless of the 'Bypass proxy server for local
requests' setting. Only addresses without dots, like http://computername:8082,
are recognised as local by MSIE, so this is the only type of address affected by
the 'Bypass proxy server for local requests' setting. So to bypass the proxy
server, set the clients to 'Bypass proxy server for local requests', and use a
dot-less address like http://computername:8082. 
Any proxy automatic configuration script in force (set via the 'Automatic
configuration' section of the 'LAN Settings' window) takes precedence over the
'Bypass proxy server for local requests' setting. When any of the 'Automatic
configuration' options are ticked on the 'LAN Settings' window, the 'Bypass
proxy server for local requests' tick box does nothing. 
If the 'Bypass proxy...' setting works for you, then in a Windows Active
Directory environment this can be set for multiple clients using Group Policy. 

source: http://www.careersoft.co.uk/chas/support/tshooter/proxy-now-what.htm

Comment 35

[nick]

As a workaround, you might want to set up a proxy auto-config file. I had the
same problem, and checked these out and they're easier than you think:

http://wp.netscape.com/eng/mozilla/2.0/relnotes/demo/proxy-live.html

The simplest example (Example 1) will let you bypass the proxy for local
addresses, which mimics the behaviour of the IE preference.

Comment 36

[philippeP]

While the problem can be BYPASSED with the use of a proxy auto-config file, that
cone can be a problem at launch time.

It occurs that the a proxy auto-config data SEEMS to be NEVER cached. 

Hence, at launch time (particularly when the home "page " is a set of sites (one
site per tab) time out occurs MOST of the time.

The final answer would then be to CACHE the  proxy auto-config data, and be able
to define an expiration date (so that it will not make a request to get the
proxy auto-config file to the web server at each launch time).

The a proxy auto-config file is very elegant and practical. It would be totally
efficient is that notion of cache/expiration could be implemented.... 

don t you think so ? Can a mozilla/firefox developer give an advice on that idea ?

Comment 37

[Christian :Biesinger (don't email me, ping me on IRC)]

? The PAC file is supposed to always be loaded before actual HTTP requests are
being made. please file a bug if you see problems in firefox 1.5 beta2 with
that... this bug is not the place to discuss that problem

Comment 38

[Phil Ringnalda (:philor)]

*** Bug 312985 has been marked as a duplicate of this bug. ***

Comment 39

[benc]

Jared: the behaviors you describe are a bit too complicated and hardwared.

Also, if we do not duplicate MS behavior, we should not use the same label, to
avoild confusing users.

Comment 40

[Carlos Rodrigues]

This bug has been open for more than 4 years, but today I still have to disable
the proxy in Firefox (or just launch IE, it's easier) to be able to access the
switches and servers on my network. It seems that there is a lot of discussion
as to what is the right way to implement this, when there isn't a _right_ way,
there is a way that fixes the bug and there is "doing nothing".

Comment #34 gives an excellent suggestion as how to implement this:

- local subnet bypasses proxy
- IANA private addresses bypass proxy

If any of these addresses turn out to be inaccessible, then the user shouldn't
check "bypass proxy for local addresses" and use a PAC provided by the network
administrator (if they require a proxy to access machines on their own internal
networks, then they should also take some time to create a PAC for their users).

The same goes for public addresses which should also bypass the proxy: if for
some reason this is required, let the net admin provide a PAC somewhere.

This isn't rocket science, and since it hasn't been fixed in all these years,
one can only assume that no one cares, and it will never be.

Comment 41

[Carlos Rodrigues]

Oh, and add names with no "." to that list too.

Comment 42

[Jared McAteer]

(In reply to comment #39)
> Jared: the behaviors you describe are a bit too complicated and hardwared.
> 
> Also, if we do not duplicate MS behavior, we should not use the same label, to
> avoild confusing users.

I don't disagree with changing the verbage on the option if the behaviour is not
the same, I was simply labeling what my opinion on how the mozilla option should
behave and how microsoft handles the option that was requested to emulate.

Personally I'd be happy if it just emulated the way IE works but, would be much
more satisfied if we could also add in no proxy for local subnet and IANA
reserved addresses as they have always been a thorn in my side with IE as well.

Comment 43

[benc]

Carlos,

You can't just decide to make the IANA PNA addresses non-proxied. Some people use proxies in their intranets. Even if Microsoft did it, it seems unlikely that we will, because the feature, assuming all that is correct, is just too complicated and clever.

We aren't going for strict IE compatability here, but we can look at functional pieces of IE features and implement them in a way that is sensible.

I know this runs the risk of sounding like a arbitrary dismissal of Microsoft, but you have to look at the larger picture:

1- As described, this feature is pretty complicated without a clear-cut benefit to the user vs. a more simple feautre.
2- There is no guarentee that MS will retain this exact behavior in the future, which means detailed emulation risks chasing a moving target. I've raised similar concerns about our attempt to mimic their WPAD feature, but I think a better example would be for someonoe to survey the enormous variation of DNS configuration implementations they have had, from Windows 95 to XP.

Comment 44

[A G]

Hi All,

MS wont be able to change the bahaviour. Thsi working is so much entrenched in the daily working that this will be taken as a regression.
And suppose MS tries to make people's lives miserable then there will be more attraction towards FF.

Many times when I try to show FF to new users, they come across this proxy barrier and stop using it.

Anyway, consider that I have some site called abc on my intranet that I have not put in proxy. So before showing me proxy authentication, FF should temperorily put abc in bypass proxy and then if the site is accessible, go to it. (Is it that IE pings the abc before trying to go there?)

If you are too unsure abt this working, provide a check box "smart proxy handle". Ping the site name before going to the internet.

Amit Gholap.

Comment 45

[A G]

"smart proxy handle" or something like that can be a good feature.
AmitG.

Comment 46

[Carlos Rodrigues]

"You can't just decide to make the IANA PNA addresses non-proxied. Some people
use proxies in their intranets. Even if Microsoft did it, it seems unlikely
that we will, because the feature, assuming all that is correct, is just too
complicated and clever."

Why not? The behavior that I suggested would be just fine for most cases.

When this turns out to be wrong for any particular case, that option can just be disabled (I'm not even suggesting that it should be turned on by default), and the network admins can provide a PAC. Worst case scenario: most cases would see an improvement, and the rest would be just as they are now.

As I said, I don't believe there is a right way to solve this. One can always go for a smart and complex solution, but I think a simple one that fits most cases is enough (and one that doesn't cause regressions on the remaining cases at that...).

Comment 47

[Des Kerrigan]

(In reply to comment #46)
> "You can't just decide to make the IANA PNA addresses non-proxied. Some people
> use proxies in their intranets. Even if Microsoft did it, it seems unlikely
> that we will, because the feature, assuming all that is correct, is just too
> complicated and clever."
> 
> Why not? The behavior that I suggested would be just fine for most cases.
> 
> When this turns out to be wrong for any particular case, that option can just
> be disabled (I'm not even suggesting that it should be turned on by default),
> and the network admins can provide a PAC. Worst case scenario: most cases would
> see an improvement, and the rest would be just as they are now.
> 
> As I said, I don't believe there is a right way to solve this. One can always
> go for a smart and complex solution, but I think a simple one that fits most
> cases is enough (and one that doesn't cause regressions on the remaining cases
> at that...).
> 


My company uses a proxy for internet addresses and a local DNS server for local addresses. I think you can assume that if the address resolves locally ie. in the local DNS or hosts file then go to it otherwise use the proxy.

My company has 300 employees and I would like to give them the option to choose FF if they want. But no bypass proxy for local addresses is a real show stopper.

Des

Comment 48

[philippeP]

I think , the Automatic Proxy Configuration feature is useful and can be a possible answer to that issue provided the browser can CACHE the info it gets from the web server whic publish the url to the proxy file.

Actually we use it, and whenever we start the browser (moz or firefox) with multiple tabs (each pointing to a specific external site) being loaded, most of them are simply not loaded because the proxy info is not yet loaded into the browser (hence it s doesn t know any specific routing info at this point in time).


the CACHE should be set'able (duration, url path,etc).

Ideally, a simple GUI could be provided (a tab in the pref panel ?)  to let admin simply (re)define the APC file.

my two cents to this story... ;)

Comment 49

[Christian :Biesinger (don't email me, ping me on IRC)]

(In reply to comment #48)
> Actually we use it, and whenever we start the browser (moz or firefox) with
> multiple tabs (each pointing to a specific external site) being loaded, most of
> them are simply not loaded because the proxy info is not yet loaded into the
> browser

which version of the browser? this is supposed to work.

Comment 50

[Carlos Rodrigues]

As I said before, the PAC is the answer only in a subset of the cases where this feature is needed. But for 90% of the cases it is cumbersome and unpractical.

Comment 51

[Des Kerrigan]

I created a PAC file and stuck it on our intranet server. It was easy enough to setup for all our local addresses. Now everyone in the company have a choice to use Firefox when specifying the PAC file location. 

This issue is now resolved for me thanks for your help.

Comment 52

[Boris 'pi' Piwinger]

Clearly, many people need this bug solved for company applications. So this is really a major showstopper. Some people say, using a PAC file solves the problem to them. Could you attach a sample to this bug, please? But most users will never get that far to use such a file. Simply setting up a checkbox as IE will serve those.

pi

Comment 53

[Boris 'pi' Piwinger]

I doubt this bug depens on bug 91587. I don't have a problem desribed there, I can exclude non-FQDN one by one. But this bug here is a real pain.

pi

Comment 54

[Jerry Baker]

Allowing IP ranges in the list of domains to ignore would go a long way towards making this bug tolerable.

Comment 56

[Christian :Biesinger (don't email me, ping me on IRC)]

(In reply to comment #54)
> Allowing IP ranges in the list of domains to ignore would go a long way towards
> making this bug tolerable.

since we don't resolve hostnames to ip address when using a proxy, that doesn't work.

Comment 57

[Charles Criddle]

(In reply to comment #56)
> (In reply to comment #54)
> > Allowing IP ranges in the list of domains to ignore would go a long way towards
> > making this bug tolerable.
> 
> since we don't resolve hostnames to ip address when using a proxy, that doesn't
> work.
> 

So What!  Just give us the ability to add a range of addresses to not use a proxy for, and save us from either adding every address (for me is 192.168.10.1 through 192.168.10.254) or using another piece of garbage software for our private net usage.  I have used Netscape and now firefox for some time now and I keep wondering why this doesn't work right.  Now I know, you are arguing over semantics and not seeing that there are many of us who don't have control over the proxy server to get to the internet but do have a private net where mine is the only computer on this net with a whole bunch of equipment that I need to talk to via DIRECT communications.  For me I call each piece of equipment by its ip address or bookmarks.  Stop the arguing and add this simple ability!

chuckc

Comment 58

[Jerry Baker]

Does FF have access to a system's route table? If so, isn't it relatively easy to determine what's local to FF? Sure, the route table might be wrong, but I don't think FF is the proper software to correct route table corruption.

Comment 59

[Patrick Cain]

I would really like to see this feature added.
 
My FF proxy exclude list contains over 30 hosts now and it's tedious to edit it every time I find something else on the intranet. It's made worse by many of our intranet servers having multiple CNAMEs for the same webserver.
 
Every single one of these webservers does not have subdomain in the addres, so a simple checkbox to not proxy addresses that don't contain dots would work perfectly for me.
 
Most of the time I end up resorting to IE for intranet browsing, especially when I'm trying to demonstrate things to people.

Comment 61

[John H. Grevstad]

I work as a systems administrator at a school, and we also have this problem. I can access the sites just fine when typing in the IP, as long as the subnet is added to the exeptions list. Hostnames, however, are not resolved from the local DNS. I need to add every single one of them to the exeptions list. I have over 600 users, most of them students, 200 new ones every year. I can't keep adding all these exeptions to every single one of them, every year!
 

After reading all the comments and adding my own, and like someone said earlier, it seems to me like most of the problems stems from FF not checking the local DNS server before going to the proxy. 

Both IE and Opera works fine, it is just FF that has this problem.


I have a background as a programmer, so I know this is not that hard to implement. Like #57 said, it seems that people are arguing about semantics, and not just adding this simple function. -As a checkbox, if nothing else...

This bug has been going for over 7 years now, why can't Mozilla understand this is a real problem? -And seeing not just Microsoft, but also other browsers (Opera) manage to implement this, why is it so difficult for FF?

Comment 62

[Des Kerrigan]

You can use a proxy.pac  file by choosing Automatic proxy configuration url. The proxy pac file can be put on the local intranet webserver  ((eg. http://intranet_server/proxy.pac ) . Its written in Javascript and is a good solution if you own a laptop which you use at work with a proxy server (proxy.pac gets loaded) and at home where you have broadband access (proxy pac is not found so doesn't get loaded).

Cheers
Des

Here is one I wrote for my company access :-


function FindProxyForURL(url, host)
  {
    if (isInNet(host, "10.0.0.0", "255.255.0.0")) { 
      return "DIRECT";
    }
    else if (isInNet(host, "172.17.107.0", "255.255.255.0")) { 
      return "DIRECT";
    }
    else if (isInNet(host, "127.0.0.0", "255.255.255.0")) { 
      return "DIRECT";
    }
    else if (isInNet(host, "203.17.206.11", "255.255.255.255")) { 
      return "DIRECT";
    }
    else
      return "PROXY 172.17.107.36:8080";
  }

Comment 63

[superber]

In the proxy.pac file, the checks can be optimized to avoid excessive DNS usage, or to protect from a local DNS failure. This is more apropiate:

if (isPlainhost name(host) ||
         dnsDomainIs(host, ".mydomain.com") ||
         isInNet(host, "10.0.0.0", "255.0.0.0"))
         return "DIRECT";

Comment 64

[Patrick Cain]

I think this bug is a perfect example of why Microsoft do so well. They implement practical & useful options whereas FF developers spend years in pointless arguments over something so simple.

PAC files are not practical for the vast majority of users who don't have a clue how to program javascript.

Comment 65

[thomas.bizer]

"I think this bug is a perfect example of why Microsoft do so well. They
implement practical & useful options whereas FF developers spend years in
pointless arguments over something so simple."

PAC files are not practical for the vast majority of users who don't have a
clue how to program javascript."

And even if one has a clue, you probably don't WANT it. For various reasons.

Not resolving hostnames to IP addresses BEFORE the no-proxy check is simply stupid. It helps preventing FF from being widely used in enterprise environments. 

If you Mozilla guys would just do a dns lookup to resolve the damn hostnames, everything would be cool. C'mon, this can't be so hard to implement. Just do it already.

Comment 66

[Eric Lawrence]

If you want to make Firefox support this feature with 99% of the fidelity of the IE version of the feature, the work to do so is trivial. You need not fully support Zones or any of the other complexity.

The (several line fix):

If no_proxies_on contains the string "<local>" and the hostname is plain (e.g. contains no dots) then you bypass the proxy. It's as simple as that. You don't need to change when you resolve DNS, you don't need to add a bunch of UI.

If network.automatic-ntlm-auth.trusted-uris also supported <local>, you would be far more compatible with most Windows-based Intranets.

Comment 67

[Kranth]

I too feel the cool browser misses this small flexibility

Comment 68

[Jason Duell]

Assuming comment 66 is accurate (comes from IE team program mgr), we should implement <local> and finally close this puppy.  

Any chance this could make ff 4?

Comment 69

[Johnathan Nightingale [:johnath]]

I'll leave the blocking call to platform drivers, but I suspect the answer is that this doesn't block, but a well-contained, reviewed, safe-looking patch with tests would be a plausible candidate for approval.

Comment 70

[Johnny Stenback (:jst)]

Not blocking, but as has been said previously, if someone contributes a safe patch for this we would most certainly consider taking this for Firefox 4.

Comment 71

[Julien Wajsberg [:julienw]]

I guess the main thing is to have a preference which would basically translates to :

if (isPlainHostName(host))
         return "DIRECT";


(for me at least, that's the requirement)

Please note also this bug prevents using the awesome bar to search on Google when one use only one word.

Comment 72

[Josh Matthews [:jdm]]

Jason, can you write a comment laying out precisely what needs to be done in this bug for a new contributor? I don't think it's reasonable to expect a newcomer to wade through 71 comments in order to determine this bug's purpose.

Comment 73

[Jason Duell]

It looks like we just need to do what's mentioned in comment 66.

  grep -r no_proxies_on *

gives a list of the files that deal with the pref.  Looks like the logic change would go into netwerk/base/src/nsProtocolProxyService.cpp.

I'd also like to look into the NTLM pref mentioned in comment 66. Cc-ing Jim Mathies, who knows NTLM much better than I.  We could either roll that into this bug, or make it a separate one.

Comment 74

[Steve Workman [:sworkman] (INACTIVE)]

Attachment: Proposed Diff

Uploaded a diff for initial feedback.  I've implemented a check for "<local>", added a boolean flag to not filter local hosts, and a check for that flag.

Please take a look and let me know what you think.

Comment 75

[Steve Workman [:sworkman] (INACTIVE)]

Attachment: v1.1 diff; includes test code

No test code was there for proxy filtering, so I added some.  This tests should test different kinds of proxy filtering, including local domains using "<local>".

Comment 76

[Honza Bambas (:mayhemer)]

Comment on attachment 557959 [details] [diff] [review]
v1.1 diff; includes test code

Review of attachment 557959 [details] [diff] [review]:
-----------------------------------------------------------------

Steve, please add following options to your hgrc and refresh the patch (it will add 8 lines of context and the name of the method hunks belong to):

[defaults]
diff=-U 8 -p
qdiff=-U 8

[diff]
git=true
showfunc=true
unified=8

As I understand this is 80:20 solution.  This will still use proxy e.g. for host included in hosts file that points to a local network.  But that is rare and solution would be complicated.  This patch is a good start.

Also, what about adding the reserved local IP ranges to the filter?

::: netwerk/base/src/nsProtocolProxyService.cpp
@@ +544,5 @@
>          }
>      }
>      
> +    // Don't use proxy for local hosts (plain hostname, no dots)
> +    if (!is_ipaddr && mFilterLocalHosts && (0 > host.FindChar('.'))) {

FindChar result should be compared to kNotFound macro.

@@ +548,5 @@
> +    if (!is_ipaddr && mFilterLocalHosts && (0 > host.FindChar('.'))) {
> +//#define DEBUG_DUMP_FILTERS
> +#ifdef DEBUG_DUMP_FILTERS
> +        printf("Not using proxy for this local host [%s]!\n", host.get());
> +#endif

Please turn all your printf's to LOG()s or just remove them.

BTW printf's are never used in the production code like this.

@@ +859,5 @@
>  
>      PRBool usePAC;
>      rv = Resolve_Internal(uri, info, flags, &usePAC, result);
> +    if (NS_FAILED(rv)) {
> +        printf("%s: Resolve_Internal returned rv(%d)\n", __FUNCTION__, rv);

You may add NS_ENSURE_SUCCESS here if you think the result is fatal.  That will give you a log automatically too.  But I am personally against that.

@@ +1112,5 @@
>  
> +        // If the current host filter is "<local>", then all local (i.e.
> +        // no dots in the hostname) hosts should bypass the proxy
> +        if (str.EqualsIgnoreCase("<local>")) {
> +            mFilterLocalHosts = PR_TRUE;

If someone removes that pref we have to allow local hosts again.  You also have to drop this flag before the cycle, or best do something like:

bool filterLocal = false;
for (filters) {
  ...
  if ("<local">)
    filterLocal = true;
  ...
}
mFilterLocalHosts = filterLocal;

Comment 77

[Eric Lawrence]

> This will still use proxy e.g. for host included in hosts file 
> what about adding the reserved local IP ranges to the filter?

If the goal is to match Internet Explorer, Chrome, and Safari on Windows, then you shouldn't filter on either of those factors, as none of the other browsers use these factors. <local> should match "plain" (dotless) hostnames only, and not attempt to use IP-mapping or other factors.

Comment 78

[Steve Workman [:sworkman] (INACTIVE)]

Attachment: Updated diff

Updated diff based on comments from [e-mail]

Honza, please take a quick look over the changes and verify, thanks.

Comment 79

[Steve Workman [:sworkman] (INACTIVE)]

Attachment: Updated diff

Noticed a test case was failing - fixed the mistake.  Had written "(kNotFound != ..." when it should have been "(kNotFound == ...".

Comment 80

[Honza Bambas (:mayhemer)]

Comment on attachment 561222 [details] [diff] [review]
Updated diff

Review of attachment 561222 [details] [diff] [review]:
-----------------------------------------------------------------

Looks good.

r+ with few minor comments.

::: netwerk/base/src/nsProtocolProxyService.cpp
@@ +856,5 @@
>  
>      PRBool usePAC;
>      rv = Resolve_Internal(uri, info, flags, &usePAC, result);
> +    if (NS_FAILED(rv)) {
> +        LOG(("%s: Resolve_Internal returned rv(%d)\n", __FUNCTION__, rv));

You should rather directly use "nsProtocolProxyService::Resolve" instead of formatting with __FUNCTION__, if you feel need for logging the method name.  Log |rv| as 0x%08x please.

@@ +1113,5 @@
> +        // no dots in the hostname) hosts should bypass the proxy
> +        if (str.EqualsIgnoreCase("<local>")) {
> +            mFilterLocalHosts = PR_TRUE;
> +            LOG(("loaded filter for local hosts "
> +                   "(plain host names, no dots)\n"));

Indention.  The second |"| on the same column as the upper one please.

@@ +1121,5 @@
> +
> +        // For all other host filters, create HostInfo object and add to list
> +        HostInfo *hinfo = new HostInfo();
> +        if (!hinfo)
> +            return; // fail silently

You can probably remove this check, new is infallible now.

::: netwerk/test/unit/test_protocolproxyservice.js
@@ +387,5 @@
> +function check_host_filters(hostList, bShouldBeFiltered) {
> +  for (var i=0; i<hostList.length; i++) {
> +    dump("*** uri=" + hostList[i] + " bShouldBeFiltered=" + bShouldBeFiltered + "\n");
> +    uri = ios.newURI(hostList, null, null);
> +    rv = pps.resolve(uri, 0); 

var uri; var rv; please.

Also, rv is in general used for storing error states.  You should use a different name for the variable.

Comment 81

[Steve Workman [:sworkman] (INACTIVE)]

Attachment: Minor updates based on Honza's review

Carrying through r+

Comment 82

[Steve Workman [:sworkman] (INACTIVE)]

Thanks, Honza.  I've submitted the patch (with minor updates as you suggested) to the try server.

Comment 83

[Mozilla RelEng Bot]

Try run for a6441c831b18 is complete.
Detailed breakdown of the results available here:
    https://tbpl.mozilla.org/?tree=Try&rev=a6441c831b18
Results (out of 229 total builds):
    exception: 2
    success: 214
    warnings: 13
Builds available at http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/[e-mail]-a6441c831b18

Comment 84

[Josh Aas]

pushed to mozilla-inbound for Steve

https://hg.mozilla.org/integration/mozilla-inbound/rev/1d490722d333

Comment 85

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/1d490722d333

Comment 86

[j.j.]

I feel somehow that needs documentation but don't know where and how. Adding keywords.

Comment 87

[Thibaut REGNIER]

Downloaded from the link on comment 83, and also from the latest Nightly build.
It is NOT fixed and MAC OSX 10.7 Lion which also has an "exclude simple host names" in the system proxy settings.

The setting is stored in the system config file /Library/Preferences/SystemConfiguration/preferences.plist
under the keys :
<key>ExcludeSimpleHostnames</key>
<integer>1</integer>

1 being exclude, and 0 do not exclude.

Comment 88

[Steve Workman [:sworkman] (INACTIVE)]

Hi Thibaut,

Thanks for updating the bug with your comments.  Can you provide some more details on your config, please?  In the Preferences -> Advanced -> Network -> Settings dialog, can you clarify whether you configured Firefox to use "system proxy settings" or "Manual proxy configuration"?  

FYI, this bugfix was designed to fix the "Manual proxy configuration" only.  Your comment suggests that you're trying to test the behavior using Mac OS 10.7 system proxy settings - if that isn't working, that's a different issue, which might need a new bug.

If you haven't done so already, please test latest Nightly with "Manual proxy configuration" to see if there's an issue there.

Thanks!

Comment 89

[Thibaut REGNIER]

The (future) documentation for this fix could be :
*****************
To avoid using a proxy for local servers, choose the manual proxy configuration of Firefox, and in the "No proxy for :" field add <local>
For instance you could have the following in the "No proxy for :"
    localhost, 127.0.0.1, <local>

*****************
Hi Steve,

Thanks a lot for your quick and precise answer. Unfortunately, I had thought from the discussion that the bug was about using the "system proxy settings" which does not work for local servers. So with this small "documentation" as an introduction I hope others will be able to know how to test your fix.

As it is today, your fix works well for me both on Windows, and on Mac OSX 10.7 if I use the "manual proxy configuration" and this is great news.


But, if I select "system proxy settings" I confirm that Firefox (and Nightly) always uses the proxy, even for local servers whereas the system configuration says it should not (tested on Windows and Mac OSX 10.7)

If you think a new bug should be opened for the system proxy, who should open it ?

Thanks

PS : on windows, the system proxy setting for local servers proxy bypass is stored in 
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\ProxyOverride
which has the value "<local>" when local servers should not be connected to through a proxy. The key is not defined if the proxy should always be used.

on Mac the setting is stored in the system config file /Library/Preferences/SystemConfiguration/preferences.plist
under the keys :
<key>ExcludeSimpleHostnames</key>
<integer>1</integer>

1 being exclude, and 0 do not exclude.

Comment 90

[Steve Workman [:sworkman] (INACTIVE)]

Thibaut,

I'm glad it's working for manual settings :)

Re opening a new bug, since you discovered it, please go ahead and open one.  Your most recent comment sounds like a good start for a bug description.  Please reference this bug as well, and either forward the bug to me via email or add me to the CC list.

Thanks!

Comment 91

[Eric Shepherd [:sheppy]]

So the change here is simply that if you're loading a URI with no dots in the hostname, the proxy is bypassed?

Comment 92

[Steve Workman [:sworkman] (INACTIVE)]

Eric,

Correct.  In Preferences -> Advanced -> Network -> Settings:  Choose "Manual Proxy Configuration" and add "<local>" in "No proxy for:".  For all domains which have no dots, requests will not go through the proxy.

Comment 93

[Eric Shepherd [:sheppy]]

This has a mention here now:

https://developer.mozilla.org/en/Proxies_in_Necko

It's worth noting that page is pretty badly in need of other work if anyone wants to take a look. :)

Comment 94

[Steve Workman [:sworkman] (INACTIVE)]

Thanks, Eric.  I added a small amendment to the mention to add that this is a configurable option.  Note also that this is a developer page - I haven't looked yet, but there might be a better place that is more appropriate for end-users or system administrators.

Comment 95

[Eric Shepherd [:sheppy]]

That's why I left the user-doc-needed flag in place. :)

Comment 96

[Steve Workman [:sworkman] (INACTIVE)]

Ooops, sorry :)

Comment 98

[Jon]

I added documentation for the <local> syntax to https://developer.mozilla.org/en-US/docs/No_Proxy_For_configuration