Closed Bug 203793 Opened 22 years ago Closed 9 years ago

PAC: solaris+IPv6 -> DNS requests from client (not delegated to proxy)

Categories

(Core :: Networking, defect)

Sun
Solaris
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: noah, Unassigned)

References

(Blocks 1 open bug)

Details

User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.3.1) Gecko/20030321 Build Identifier: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:1.3.1) Gecko/20030321 When I upgraded from mozilla 1.3.0 to 1.3.1, mozilla started trying to do all of its host lookups using our interal DNS, instead of sending the request to the proxy described in the proxy auto config (.pac) file. This has happened for everyone that I know that has IPV6 enabled on their machine (Solaris 8). If IPV6 is not enabled (I have only tested this on a different machine), the same mozilla binary works fine with the same .pac file. As an aside, could there please be some sort of feedback from the "reload" button; an invalid filename currently produces the same results as a valid one. Reproducible: Always Steps to Reproduce: 1. point the proxy auto config URL to file:///usr/.../east.pac 2. try to go to www.google.com Actual Results: I get the hostname could not be found popup dialog box Expected Results: should have gone to our proxy and asked it to find www.google.com and loaded the page. This works fine if I point the manual HTTP proxy config at our proxy server.
Status: UNCONFIRMED → NEW
Ever confirmed: true
strange... very little has changed between 1.3 and 1.3.1 in the area of proxy auto config or networking in general. could you try creating a new mozilla profile just for kicks? is the PAC file indeed loaded using a file:// URL?
Please post your PAC file. If the problem goes away w/ IPv6 off, there are a couple known causes. Fixing error messages is bug 121038.
QA Contact: httpqa → pacqa
Summary: PAC file (proxy auto config) ignored → PAC: problem on solaris/IPV6
Here's a simple version of the PAC file that doesn't work for me: function FindProxyForURL(url, host) { return "PROXY webcache2.East.Sun.COM:8080"; } I loaded this file with the URL file:///home/beckn/east.pac
Also, a new profile didn't do anything differently.
OS: SunOS → Solaris
Reporter, is this still a problem? If not, we can close as WORKSFORME.
Since sun is distributing 1.4, can we get an update? There were also some reports that for a while, proxy requests would still trigger DNS resolution on the local system, but I think this has gone a way (I'm in the middle of verifying the platforms one by one).
QA Contact: pacqa → benc
Roland: can you check this out for me? If you need a PAC config and/or a way of tracing your DNS activity, I can help you with that remotely.
Summary: PAC: problem on solaris/IPV6 → PAC: solaris+IPv6 -> DNS requests from client (not delegated to proxy)
I am not sure how this should actually work. Currect me if I am wrong - Mozilla uses the OS API for DNS lookups (gethostbyname(), getipnodebyname()) and that cannot be redirected to a proxy from within the application (or maybe the getipnodebyname() doesn't honor the settings). Where is the code which handles that stuff (LXR URL, please) ?
(In reply to comment #8) > I am not sure how this should actually work. > Currect me if I am wrong - Mozilla uses the OS API for DNS lookups > (gethostbyname(), getipnodebyname()) no, getaddrinfo is what's used, iirc. > and that cannot be redirected to a proxy > from within the application (or maybe the getipnodebyname() doesn't honor the > settings). Well, really, no DNS lookup should happen in the proxy case, the proxy should just get the url. socks proxies are different, but there's a different xp bug that these are done client-side.
note that this contradicts with bug 136789 (which asks that the client will do a lookup)
Jo: that bug is not talking about PAC mode.
-> default owner
Assignee: darin → nobody
Component: Networking: HTTP → Networking
QA Contact: benc → networking
URL: N/A
Blocks: IPv6
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.