Closed Bug 85898 Opened 24 years ago Closed 24 years ago

PAC: Fails if local host name does not resolve

Categories

(Core :: Networking, defect)

Product:
Core
Component:
Networking
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: jhatax, Assigned: srgchrpv)

References

Details

(Keywords: relnote)

Attachments

(1 file)

proxy auto config as promised
270 bytes, text/plain
Details
From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.1) Gecko/20010607 BuildID: 2001060703 Mozilla has an option of specifying an automatic configuration script to set up proxies for HTTP, FTP, Gopher, SOCKS, etc. Even after selecting the option and indicating a file (that is located on a server on the Local LAN), Mozilla is unable to retrieve the file and initialize the proxy settings. I shut down the computer and retried but Mozilla did not respond. This works correctly in IE4.x and 5.x. this is an important feature because most corporate intranets allow connecting to the Internet through proxies which may change from time to time. Reproducible: Always Steps to Reproduce: 1. Edit -> Preferences -> Advanced -> Proxies 2. Enter the name of a file that is an automatic configuration script 3. Actual Results: Mozilla did not download the file and tried to directly connect to the Internet. Expected Results: Mozilla should download the local file and use the settings in the file to connect to the Internet. This works with netscape 4.x
*** Bug 85899 has been marked as a duplicate of this bug. ***
Here is my recent experience with PAC's and mozilla... For some background information, with moz 0.9, both Windows and Linux mozilla milestone builds were able to use the attached PAC by setting the proper URL in Edit > Prefs > Advanced > Proxies. With moz 0.9.1 Windows milestone [Mozilla/5.0 (Windows; U; Win98; en-US; rv:0.9.1) Gecko/20010607] the PAC works, and is how I'm accessing bugzilla right now :) No complaints at all. With the moz 0.9.1 Linux milestone [Mozilla/5.0 (X11; U; Linux 2.2.16-22 i686; en-US; rv:0.9.1) Gecko/20010607] the PAC fails, as does setting the proxy settings to Manual and entering its IP and port accordingly. All attempts to access any sites result in 'XXX could not be found. Please check the name and try again.' The Linux build shows the following at run-time (run as ./mozilla/mozilla from my home directory, www.google.com is my home page): -->CUT HERE<-- ./mozilla/run-mozilla.sh ./mozilla/mozilla-bin MOZILLA_FIVE_HOME=/home/cnoe/mozilla LD_LIBRARY_PATH=/home/cnoe/mozilla:/home/cnoe/mozilla/plugins LIBRARY_PATH=/home/cnoe/mozilla:/home/cnoe/mozilla/components SHLIB_PATH=/home/cnoe/mozilla LIBPATH=/home/cnoe/mozilla ADDON_PATH=/home/cnoe/mozilla MOZ_PROGRAM=./mozilla/mozilla-bin MOZ_TOOLKIT= moz_debug=0 moz_debugger= Registering plugin 0 for: "*","All types",".*" PAC:Loading PAC from http://intranet1/proxy.pac Error loading URL http://www.google.com/ : 2152398878 [quit mozilla here] *** Unloading Proxy Auto Config... -->CUT HERE<-- With an occasional spattering (unreproducible, so far) of: -->CUT HERE<-- Gdk-CRITICAL **: file gdkwindow.c: line 716 (gdk_window_ref): assertion `window != NULL' failed. Warning prev sibling is not in our list!!! -->CUT HERE<-- After the 'Error loading URL http://www.google.com/ : 2152398878' above. The proxy.pac is as follows: -->CUT HERE<-- function FindProxyForURL(url, host) { if (dnsDomainIs(host, ".ci.prescott.az.us")) return "DIRECT"; if (dnsDomainIs(host, ".cityofprescott.org")) return "DIRECT"; if (dnsDomainLevels(host) > 0) return "PROXY quintana:8080"; return "DIRECT"; } -->CUT HERE<-- I know that 'quintana' is able to resolve on the box, but just in case I updated the proxy.pac to use it's IP address instead of dns name and it still failed in the same way. Also tried blowing away the local ~/.mozilla directory, in hopes that it was a bad config option or something, but no luck.
I've found the solution (to my problem noted above)... The hostname of the box mozilla was running on was not resolvable, and that is what was keeping it from working correctly. No error or warning messages that said anything to this effect. I didn't realize our DNS server (for this box) was down until today and once I remedied that, the linux mozilla milestone 0.9.1 worked perfectly with PAC's and all. Should I report this as a 'new bug' - ie 'If local hostname not resolvable, print a message to that effect or tell the user to fix it.. otherwise the browser will just not work'?
updated summary (temporary fix) you mean that "workstation.domain.com" was not resolvable, and you fixed it and the problem went away? I have not analyzed the DNS performance of a PAC file, you may have found a new problem.
Summary: Mozilla does not work with an automatic configuration script for its proxy server settings → PAC: DNS resolution problem
exactly. the address of the proxy (in the pac itself) was always resolvable (or specified as an IP addr). when the *workstation name* could not be resolved through DNS the problem was observed. Once the DNS server was updated with the host info for my workstation, and was therefore resolvable, my problems stopped. This was only observed on the Linux 0.9.1 milestone and appears to be a different bug than the originally reported #85898 which was a report against Windows NT. Haven't tried any more recent builds yet.
SPAM: ccing self
Weird. So is Chris Noe's problem being split off into a separate bug, or are we taking it here? Manoj, are you still there? And having problems?
Ok, here's what I'm going to do. Manoj has an older PAC bug of a similar nature (bug 81272). When he filed it, he was still using 2001050515. I'm going to paste his reported comments from this bug over to that one as an update. Then, updating platform, and summary to make this the DNS bug reported by chris.noe@cityofprescott.net.
OS: Windows NT → Linux
Summary: PAC: DNS resolution problem → PAC: Fails if local host name does not resolve
+mozilla 1.0, relnote - this needs to be handled or documented. ->new neeti: can someone look at this problem?
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: mozilla1.0, relnote
QA Contact: benc → pacqa
*** Bug 81272 has been marked as a duplicate of this bug. ***
Manoj is here and is experiencing the very same problems still with a newer mozilla 2001062815.
This is a loader problem right? So this blocks ANY PAC for the unlucky computer. Do we know if this is just a forward lookup or a reverse lookup or both?
Can you estimate a limit to the size of file or the level of recursion? Right now, the information is more important than erroring gracefully. We have other js and pac bugs that need to be fixed yesterday.
(whoops...wrong bug)
Chris Noe: have you reported another bug for your bug?
_basic: this is the first and only bug I've ever reported :) And, from testing against the 0.9.2 milestone build for Linux, it's still reproduceable. benc: I'm uncertain if the bug is caused by the failure of the reverse or forward lookup. See the writeup below. Will try to isolate it soon. It's kind of a pain b/c our dynamic dns server will rewrite some of the records as soon as I touch them, but I'll give it a shot :) Here's the scenario (in excruciating detail in hopes of making the bug easier to squash): My linux box is named cop317.cityofprescott.org. It runs moz. :) Most of the time, when my box needs to renew its DHCP lease, it will remember to send its hostname as part of the dhcp request, so that our dynamic dns server can create an A record (with matching PTR) with that hostname, and its DHCP assigned IP address. Sometimes, the dhcp client on this box forgets to send the hostname as part of its request, and the dynamic dns server updates using 'cop317cityofprescottorg.cityofprescott.org' as the hostname, creating new A and PTR records for the same IP, but for that bogus hostname. It removes the valid 'cop317.cityofprescott.org' address at the same time. From that point on, my box can't figure out what it's own name is. I can't just throw it in /etc/hosts, because it's dhcp assigned, and will change soon enough. And I have yet to figure out wtf is wrong with the dhcp client that makes it work half of the time, and bugger out the other half of the time. It's not something that will occur in a normal, well-configured box, but at the same time it took me a few days to figure out why mozilla wasn't working (which led me to discover the dhcp client problems above). Not even sure if this is worth a bugfix, unless it's simple; maybe just a mention in the release notes. I do know that it's a *very* stock rh7 box, and if a lot of other folks are (a) using dhcp (with this buggered dhcp client) and (b) running mozilla with a PAC, they will quite possibly run into this problem. Will attach PAC.
arg - forgot to mention. the workaround so far, to get mozilla to serve me pages, has been to just add: cop317.cityofprescott.org 172.30.x.xx to /etc/hosts. Everything works great once I do that. The problem is that I have to keep updating /etc/hosts every other day because my lease IP changes :)
I assume you use cop317.cityofprescott.org to access your pac file?
cop317.cityofprescott.org grabs the pac from http://intranet1/proxy.pac. intranet1 is an internal webserver on our network.
serge, I have been told that you are the person to look at pac stuff. If I am wrong, please assign back to me.
Assignee: neeti → serge
Component: Networking: HTTP → Networking
Looking at this again, I wonder if bbaetz's fix for bug 80363 will have any effect on this -- if the local host name isn't resolvable, the myIPAddress assignment might fail.
Umm the fix there is mainly for the Mac where there isn't a dns entry.
Sure, that's why that problem occurs, but the fix is to catch an exception thrown by myIPAddress and assign a dummy value in the sandbox creation code. It seems conceivable that if the local hostname couldn't resolve, a similar exception might be thrown. But since I'm not sure anyone's ever reproduced this problem, it's hard to test. cc'ing bbaetz in case this is related.
Yep, my patch will fix this. Just out of interest, what does 4.x report for myIPAddress (I think thats the capitalisation)?
Depends on: 80363
This should be fixed now on the trunk. I'd still like to know what myIPAddress returns on 4.7, though.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
I wrote a simple PAC that called myIpAddress (I believe this is the capitalization the spec uses) and spits the result out in an alert (NS4) or a dump (moz). The values printed were equivalent -- dotted quad notation. I don't know if there's any magic formatting going on anywhere, though.
tingly - no, I wanted to know what IP address was reported when it couldn't look up the domain name. My patch just returns 127.0.0.1, but I don't know what 4.x did.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: