From Bugzilla Helper: User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.4.3 i586) BuildID: 2001060811 After setting the auto proxy url in Mozilla to: http://www.tau.ac.il/tau.pac every url access doesn't work(displays an alert box - 'connection was refused...') Pressing the 'Reload' (for the proxy script) button doesn't do much but displaying in the terminal: PAC:Loading PAC from http://www.tau.ac.il/tau.pac (actullay any address, even bogus, will result in a similar message). This url auto-script works fine with netscape v4.7x. It also didn't work with previous versions of Mozila such as 0.8,0.9. Reproducible: Always Steps to Reproduce: 1.try setting that url as auto proxy script 2.try browsing www.mozilla.org or anything else...

this may a dup of bug 84647. alternately, the problem could be caused by the use of isPlainHostName in tau.pac -- see bug 79502.

-> networking

I've read these two bugs. The script uses that isPlainHostName, but it returns several proxies. I've tried to test it manually - can Mozilla support several? None of them seems to work. Besides - why doesn't Mozilla makes an alert when I insert a bogus url for the script? Here is tau.pac: (shortened) function FindProxyForURL(url, host) { if (isPlainHostName(host) || dnsDomainIs(host, "www.internet-2.org.il") || dnsDomainIs(host, "www.sports-center.co.il") || ... dnsDomainIs(host, "webspirs.ziur.co.il")) return "DIRECT"; else if (dnsDomainIs(host, "www.iop.org") || dnsDomainIs(host, "www.publish.csiro.au") || ... dnsDomainIs(host, ".swetsnet.nl") || shExpMatch(host, "egj.lib.uidaho.edu") || shExpMatch(host, "open.academic.telebase.com") || shExpMatch(host, "www.biochemj.org") || shExpMatch(host, "www.turpion.org") || shExpMatch(host, "www.hbuk.co.uk") || shExpMatch(host, ".bids.ac.uk") || shExpMatch(host, "www.ed-phys.fr") || shExpMatch(host, "biomednet.com") || shExpMatch(host, "www.journals.uchicago.edu") || shExpMatch(host, "www.imrn.org") || shExpMatch(host, "www.acm.org") || shExpMatch(host, "www.jbc.org") || isInNet(host, "194.209.48.0", "255.255.255.0") || isInNet(host, "208.228.158.0", "255.255.255.0")) return "PROXY 132.66.16.6"; else return "PROXY proxym.tau.ac.il:8080; " + "PROXY wwwproxy.ac.il:8080; " + "PROXY www.tau.ac.il; " + "PROXY 132.66.16.23:8080; " + "PROXY 128.139.197.54:8080; " + "PROXY 132.66.16.6"; }

Well, the migration bug is just a symptom, basically it means PAC used to work, but doesn't now. Each of those reports is actually going to be a specific problem, like this. Let's work backwards. Connection refused means that that some connection (client-proxy) was attempted and failed. This error could be improved, but the point is that you should test the proxy you think you are hitting w/ a manual config. For example: return "PROXY 132.66.16.6"; needs a port number. If you can connect, then isolate lines of the pac file by removing them until you find a working version...

SPAM: adding PAC

pac

Serge, can you take a look at these PAC issues? Thanks - Jussi-Pekka

I've searched a little while, and it seems that while Netscape can "guess" the port in .pac line such as "PROXY 132.66.16.6" Mozilla can't. After some guessing it turned out to be 80. It works well in manual proxy, as the only proxy in both Netscape and Mozilla (0.9.1). The minimal working .pac file that works seems to be function FindProxyForURL(url, host) { return "PROXY 132.66.16.6:80"; } which works in them both. But trying to add another proxy BEFORE doesn't work in Mozilla, so return "PROXY 128.139.197.54:8080;"+ "PROXY 132.66.16.6:80"; only works in Netscape. But return "PROXY 132.66.16.6:80"+ "PROXY 128.139.197.54:8080"; works in both. Maybe Mozilla gives up on the first proxy attempt? Two other "bugs" : 1. Entering "0080" as the port in manual proxy gets it as 0,so I must enter "80". 2. If the proxy file has been changed, and I press 'reload' it has no effect, Mozilla remembers and acts upon the old one. I mean if I use file://home/bla/1.pac, as the proxy file, and then edit it outside Mozilla, then press reload, then 'ok', it has no effect. Also changing to 'direct proxy' and then to 'auto proxy' with the same url doesn't do anything. Only closing and starting mozilla uses the new .pac file. Liav

Yes, Mozilla will currently ignore everything after the first proxy, so if it fails you probably won't get connectivity (it will default to a direct connection, I think). This is recorded in bug 84798, for which a fix is almost ready. The failure of the reload button is also new; this is bug 79246. The thing about the port number (port 0080 interpreted as 0) I haven't seen before; you may want to search for that and enter it as a separate bug. This seems like lower priority than a number of other proxy bugs, though. As for status of things that currently don't work in your PAC, a fix to make isPlainHostName work (bug 79502) should be checked in soon, and _basic and I are close to having fixes for bug 79057 and (as I mentioned earlier) bug 84798.

downgrading; since bug 79057 is fixed the PAC should function, just not completely (failover).

bug 65034 looks like fixed looks like the remaining issues are: bug 84798 (failover -- not getting fixed anytime soon) bug 91630 (default to port 80. May get fixed by patch in bug 105335 if approved)

to default owner

Temporarily "futuring" all PAC&SOCKS bugs to clear new-networking queue. I will review later. (I promise) If you object, and can make a case for a mozilla 1.0 fix, please reset milestone to "--" or email me.

Looks like the only outstanding issue here is the failover issue, and that is covered in bug 84798. In that case, this bug is really a dup of bug 84798 so I'm marking it as such. If I'm wrong and there is something else here beyond that bug, then please reopen and state what that is. *** This bug has been marked as a duplicate of 84798 ***

I've been trying to keep each bug a single report of a file w/ a problem. This allows us to investigate a file w/ multiple failures. Even though a bug of one dependency is sort of a dupe, I it makes the dependency tree inconsistent.

Liav: This is fixed now, please try the most recent build and RESOLVE/FIXED if everything works now.

Reporter: please try again using a recent nightly build from <http://ftp.mozilla.org/pub/mozilla/nightly/>. If it works for you then, please resolve this bug as RESOLVED/FIXED. Thank you.

fixed.

V: fixed.