48718 - Proxy: "No proxy for" does not support "*.domain" format (leading wildcard only)

Status: VERIFIED FIXED

(Core :: Networking, defect, P3)

Description

[Jason Eager]

I can't use mozilla for submitting forms on my companies intranet because
mozilla is ignoring the
"no proxy for" field set in preferences and getting those pages from the proxy
anyways.

Marking nsbeta3 and 4xp because this bug keeps me from using mozilla for day to
day tasks
on the intranet. I have to use IE instead. :-(

Comment 1

[Jason Eager]

Ok, NOW I'm marking it 4xp and nsbeta3.

Comment 2

[Gagan]

Tom, can you confirm?

Comment 3

[Gagan]

If this was indeed still a problem then this is a plus!

Comment 4

[Jason Eager]

Ok, after a bit of experimentation, i've found that the problem isn't quite as
serious as I originally thought, but it is still BAD, and needs to
be fixed before RTM.

As per other web browsers, I originally entered "*.trimble.co.nz; *.trimble.com"
into that field, and that did NOT work (ie all requests still went
through the proxy). Then I started entering in complete domain names
("helpdesk.trimble.co.nz", "webfoot.trimble.com") and that DID work. But
I have to enter the full domain name for EACH web site that I don't want to go
through the proxy. My list will probably be 40 domain names
or longer by the time I've found all the domains that break from going through
the proxy.

This is NOT an acceptable work-around for RTM. It's bloody annoying for me, it's
going to be IMPOSSIBLE for people who don't even understand what a proxy is. We
NEED to handle wildcards properly in the no proxy field so a sys-admin can set
it ONCE and forget about it.

Also, we need to tell users (ON the dialog) that the separator between items is
a comma and NOT a semicolen. IE (blah) uses ";" to separate
items in that field, and I only realized that I was supposed to be using commas
instead after reading the code!

Changed summary to state the real problems. The problem isn't that much better
from the user's point of view, they're going to throw in "*.companyname.com",
find that it doesn't work, and then assume that the feature doesn't work. It
still needs to be nsbeta3+

Comment 5

[Gagan]

Ah this is a known problem (I forget the dup) but the simplest workaround is to
remove the * and everything would work just fine. So change your entries 

from *.trimble.co.nz to .trimble.co.nz
and *.trimble.com to .trimble.com 

the other bug is just about interpretting *. Anyway marking nsbeta3- since it
has a workaround and otherwise no_proxies_for does work. 

Comment 6

[Jason Eager]

WOOHOO!! That worked!
Given this workaround, I agree with nsbeta3-. But the POOR DOCUMENTATION problem
still stands. I'm going to open a new bug for that.

Most users wouldn't think to use host.deny and host.allow syntax in that field.
:P :-) (It's a HORRIBLE syntax anyways...since WHEN should white space == "*" ?)
We should eventually change it to handle *'s anyways..that shouldn't be that
difficult.

I'm marking this bug relnote3 if my other (new) bug isn't fixed for nsbeta3. One
way or another, we need to tell the user what the syntax for that field is. I'm
changing the description of this bug to drop the "poor documentation" part,
because that's going to be the new bug.

Comment 7

[Jason Eager]

Ok, I've created bug 49858 to deal with the user-interface issue.

If we fix that, then relnote3 can go away.

Downgrading severity to "trivial"

Comment 8

[Jason Eager]

Removing relnote3 because the fix for bug# 49858 was checked in. Now this bug 
doesn't make people think that excluding domains from proxies is broken, it's 
just merely annoying for people who disagree with host.deny parsing. :P :-)

Comment 9

[Jesse Ruderman]

Does this create problems when importing settings from NS 4.x?  If it does, it 
needs a relnote.

Comment 10

[GAThrawn]

We have a number of test servers referred to purely by their IP addresses,
currently the only way to put these into Mozilla's "No proxy for" box is to
specify each IP address individually. As they're class B IP addresses the first
two bytes of the IP addresses are always the same, it's the last two that differ.

eg The IP addresses 151.101.20.3, 151.101.20.4 and 151.101.55.2 all need to be
added in, currently they would all need to be entered individually.

There doesn't seem to be any way to specify a wildcard for the end of an
address, as "151.101.*" doesn't work, neither does "151.101." or "151.101".

Comment 11

[benc]

qa to me, -qa wanted
cleared keywords, nominated nsbeta1, nsdogfood
severity -> major, platforms to all, reset milestone
Remaining issues, still in mozilla 0.9:

1- Migration: will the new format break migrated prefs?
2- Documentation: is this detailed and correct outside the Prefs UI note
3- IP network address wildcards (bug 80918)

Comment 12

[benc]

RELNOTE:
"
No Proxy for: does not support the *.domain syntax. If you migrate, remove any
"*" characters that appear.
"

Comment 13

[Denis Antrushin]

Attachment: allow '*' as prefix for no-proxy domains

I'm not sure if wildcards in the middle of domain names (like www.*.com) makes
sense. I'm also not sure if assignee of bug 80918 gonna fix domain name
wildcards as well as wildcards for IP addresses, but allowing '*' as prefix
in no-proxy domain names is as simple as 'np++;' :-)

I also suspect that line 650 of nsProtocolProxyService.cpp should read
hp->host = new nsCString(np, (portLocation? portLocation : endproxy) - np);
instead of
hp->host = new nsCString(np, endproxy-np);
i.e., don't include port number in hostname portion.
(I assume, that nsIURI::GetHost() strips out port number)

Comment 14

[Gagan]

I'll try and wrap this in earliar.

Comment 15

[basic]

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

Comment 16

[Gagan]

to 0.9.9

Comment 17

[Jeff Qiu]

What IE says:
"
You can use wildcards to match domain and host names or addresses - for
example, www.*.com; 128.*, 240.*, *.mygroup.*, *x*, and so on."
IMHO, we should make sure their no-proxy lists still work when users transfer 
from IE to mozilla. 

I'm trying to figure out how to support one wildcard in domain names or ip 
addresses. Patch coming...

Comment 18

[Denis Antrushin]

You can fork off perl interpreter to get power of full futured regexp
engine matching wildcards

Comment 19

[benc]

gagan: can you retarget or future or reassing this bug?

This bug discussion is focused on improving wildcard support, so I've removed
the meta aspects of this bug to bug 172083.

Comment 20

[Simon Fraser [no longer active]]

How does this bug related to bug 80918?

Comment 21

[benc]

This talks about how various hostname and DNS wildcard combinations would be
desirable and/or needed for 4xp.

The other bug is about wildcards for IP addressing. The order of significance
for DNS and IP addresses is different, so the underlying logic seems like it
could be different as well.

Comment 22

[benc]

reset owner and milestone. Chimera depends on this now.

Comment 23

[Doug Turner (:dougt)]

reassigning to darin.

Comment 24

[Darin Fisher]

now that bug 80918 has been fixed, what really remains?  is this bug simply a
duplicate of that bug?

Comment 25

[Gustavo Chaves]

How can I specify for Mozilla that it should use "no proxy for" URLs in which
the server name contains no periods ('.')?

My problem is that in my intranet there are lots of pages refering to others
with URLs not using the FQDN of servers but their simple names.  Mozilla is
using the proxy for these links and I would like to tell it not to do so.

Perhaps one could extend the sintax of the "no proxy for" line in a way similar
to what you can use to specify searches in Google.  Things like "site:.br". 
Here are a two suggestions out of my hat:

* "re:/REGEXP/": this would allow the specification by a regular expression,
which, BTW, would allow me to solve my problem with "re:/^[^.]+$/".

* "net:IPADDR[/MASK]": this would allow the specification by IP addresses and
netmasks.  Note that this would force the browser to perform name resolutions
even though it's using a proxy, which would have a performance impact.

Comment 26

[benc]

darin: I think this is a bit broader than the IP wildcard bugs you fixed. See
comment #17. Some of those forms of wildcards don't make sense, maybe we
shouldn't support everything...

Comment 27

[benc]

Gustavo: see bug 91587 for your concerns about hostnames. As for extending the
syntax further, I think we should stay away from that, if you want to get fancy,
use PAC. We would be better off thinking about either of the following:

1- freezing the behavior and documenting it.
2- testing vs. IE for interoperability.
3- adding aspects that are more basic, like IPv6.

Adding features to the manual inteface is really a losing proposition because
there is a three dimenionsal complexity problem (DNS addressing, IP addressing,
and protocol support).

Keeping PAC fully functional would be better, we could always create a manual
interface that is a front end for PAC.

Comment 28

[Gustavo Chaves]

benc: Ok, I agree with you about keeping the syntax simple.  It's just that it's
so simple as to not being enough for my needs.  But I'm not going to push it.

From what I read in this thread an in bug 91587 there seems to be different
issues being discussed together.

While reading all this I found out an answer to my problem.  Since I use just a
small number of internal webservers I put all their names in the "no proxy for"
form along with my domains name.  It's like this:
".cpqd.com.br,gnu,mailer,intranet,verdoc".

This way, when I follow links like "http://gnu/..." Mozilla doesn't use the
proxy as I wanted.

This works and is fine while the number of internal webservers is small. 
However, if one had to specify tens of servers it would be really usefull to be
able to tell Mozilla to use "no proxy for" URLs where the server name has no
dots in it.

BTW where can I find documentation about the syntax of a PAC file?

Comment 29

[philippeP]

Now I use PAC, and I am very happy with it as it manage all the exceptions quite
efficiently. however I have ONE question : what happens if the client (mozilla)
can t get connected to the web server where the proxy definitions are stored ?
is there any local cache on the mozilla client (in case of web server down for
instance) ?

We should have a way (not necessarily in the UI. the about:config method is
fine) to tell mozilla to cache the PAC definitions (if it is not the case) and
tell him about the TTL in an failed to connect to PAC server scenario.

My two cents.. :)

Comment 30

[Darin Fisher]

you can also just store your PAC file on the local filesystem, and enter a
file:// URL into the proxy preferences panel.

Comment 31

[nDorfin]

I have to append the port number (app server port) of a LAN host in Firebird's
"No Proxy for:"  dialog before i can actually view the host on that port :/

e.g. I'm trying to reach: http://hostname:7001
If i enter the following in my "no proxy for:" dialog:
"[..], hostname" -  it doesnt work
but
"[..], hostname:7001" - it does.

Comment 32

[benc]

nDorfin: please create a new bug for thsi problem.

Comment 33

[benc]

From looking at the code, "*" is allowed as a first character on each filter
term. By ignoring it, the behavior  gives the effect of wildcard support, but
only for prefixes.

RESOLVED/FIXED by depends on 80918.
Testcases and verification coming up.

Comment 34

[Robin Monks]

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

Comment 35

[benc]

V/fixed:
These lines were added in bug 80918:
            if (str.First() == '*')
                 startIndex = 1; // *.domain -> .domain
http://bonsai.mozilla.org/cvsview2.cgi?diff_mode=context&whitespace_mode=show&root=/cvsroot&subdir=mozilla/netwerk/base/src&command=DIFF_FRAMESET&file=nsProtocolProxyService.cpp&rev2=1.44&rev1=1.43

I've tested a couple domains w/ leading "*" in a couple cases. Re-opened the
last dupe, because that was a report this is broken in Firefox.