Open Bug 1121443 Opened 8 years ago Updated 2 years ago

Firefox ESR is slow when using a proxy.pac file in an entreprise environment with proxy infrastructure

Categories

(Core :: Networking: HTTP, defect, P5)

x86_64
Windows 7
defect

Tracking

()

UNCONFIRMED

People

(Reporter: andre.nanquette, Unassigned)

References

Details

(Whiteboard: [necko-backlog][proxy])

Attachments

(1 file)

User Agent: Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; WOW64; Trident/5.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; Media Center PC 6.0; .NET4.0C; .NET4.0E)

Steps to reproduce:

Using Firefox 17.0.11esr and all later versions in an enterpise environment with a proxy.pac file (Automatic proxy configuration URL).
Is still the cas in the latest versions of Firefox.


Actual results:

Using a PAC file, Firefox does a DNS request and - depending on your OS and configuration - a NetBIOS request for each object it loads. This can lead to a huge slowdown of the overall operation, especially when your configured DNS servers are not able to resolve internet names (as it is often the case in organizations where you connect to the internet through a proxy).


Expected results:

The only DNS requests the browser should be performing are to resolve the proxy(ies) address(es), that's all. To my knowledge it should NEVER perform a DNS request for the OCS hostname of the objects it has to load as long as the PAC file doesn't provide a DIRECT directive for the specific host.
(In reply to André Nanquette from comment #0)
> Using a PAC file, Firefox does a DNS request and - depending on your OS and
> configuration - a NetBIOS request for each object it loads. This can lead to
> a huge slowdown of the overall operation, especially when your configured
> DNS servers are not able to resolve internet names (as it is often the case
> in organizations where you connect to the internet through a proxy).

I'm a little confused. Are you saying that if you are connecting with Firefox through a proxy configured via a PAC, and you connect to, say, "http://www.mozilla.org", you think it's a bug that there is a DNS request for www.mozilla.org ?

If that's not quite what you're saying, can you be more specific and/or clarify what I've misunderstood?
Component: Untriaged → Networking: HTTP
Flags: needinfo?(andre.nanquette)
Product: Firefox → Core
Do you specify a socks proxy in your pac file or just a normal http/https proxy ?
IIRC (it's been a long time), this kind of behavior depends on the specific PAC you're using. The browser itself shouldn't automatically perform lookups, but the blob of JS in the PAC can easily cause lookups if not coded carefully.

I think you'll need to attach your specific PAC and/or verify that this reproduces with a minimal/dummy PAC that is known to never trigger lookups.
Here is a anonymized version of our PAC file.
Flags: needinfo?(andre.nanquette)
(In reply to :Gijs Kruitbosch from comment #1)
> (In reply to André Nanquette from comment #0)
> > Using a PAC file, Firefox does a DNS request and - depending on your OS and
> > configuration - a NetBIOS request for each object it loads. This can lead to
> > a huge slowdown of the overall operation, especially when your configured
> > DNS servers are not able to resolve internet names (as it is often the case
> > in organizations where you connect to the internet through a proxy).
> 
> I'm a little confused. Are you saying that if you are connecting with
> Firefox through a proxy configured via a PAC, and you connect to, say,
> "http://www.mozilla.org", you think it's a bug that there is a DNS request
> for www.mozilla.org ?
> 
> If that's not quite what you're saying, can you be more specific and/or
> clarify what I've misunderstood?

What I want to say is that it should send the request to the proxy and not do an internal LAN DNS request towards the internal network DNS servers which can not resolve internet names.
(In reply to Matthias Versen [:Matti] from comment #2)
> Do you specify a socks proxy in your pac file or just a normal http/https
> proxy ?

Just a normal HTTP/HTTPS proxy, no socks.
Sometimes speculative dns queries happen before the pac is resolved. This won't actually slow you down - because nothing blocks on their completion - but they will confuse your analysis. network.dns.disablePrefetch can turn it off and help you debug.

(but you say we shouldn't do that when a proxy is configured! unfortunately you are using a pac file which might be going DIRECT, so we do it just in case. but in any event, like I said nothing depends on the result of the query finishing quickly)
(In reply to Patrick McManus [:mcmanus] from comment #7)
> Sometimes speculative dns queries happen before the pac is resolved. This
> won't actually slow you down - because nothing blocks on their completion -
> but they will confuse your analysis. network.dns.disablePrefetch can turn it
> off and help you debug.
> 
> (but you say we shouldn't do that when a proxy is configured! unfortunately
> you are using a pac file which might be going DIRECT, so we do it just in
> case. but in any event, like I said nothing depends on the result of the
> query finishing quickly)

We did already set "network.dns.disablePrefetch" to TRUE, before doing the test, so this is not the reason.
It is really visible as a change from Firefox ESR 17.0.10 to 17.0.11 and later.
So, what did change from 17.0.10 to 17.0.11 that causes this change in behaviour?
(In reply to André Nanquette from comment #8)
>
> So, what did change from 17.0.10 to 17.0.11 that causes this change in
> behaviour?

I don't know.

Back in the description you said "all later versions of firefox". Did you mean firefox 34/35 or did you mean esr dot releases when you said that?
(In reply to Patrick McManus [:mcmanus] from comment #9)
> (In reply to André Nanquette from comment #8)
> >
> > So, what did change from 17.0.10 to 17.0.11 that causes this change in
> > behaviour?
> 
> I don't know.
> 
> Back in the description you said "all later versions of firefox". Did you
> mean firefox 34/35 or did you mean esr dot releases when you said that?

Both versions (Stanndard and ESR) are having this behaviour. I don't know exactly which was the last standard version that did not have this "problem".
please try it with 34 or 35 for me and we'll debug it there. I do want to debug it with you if its still an issue.

 17.x is just plain not supported and its not clear that if any fix were needed here it would meet the esr porting criteria to the latest esr.
I've tried it with Firefox ESR 31.5.0 which is the latest version, and it is still slow.
The problem seems to be linked to the interpretation of the PAC file.
For every object of every page that the browser has to show, instead of directly sending the HTTP request to the proxy, it does first a DNS and a NBNAME query of the hostname of the URL of the object. This causes a timeout for some seconds since there is no answer in our internal network for these requests.
Does someone have a recommendation for the structure and commands in the PAC file?
What is supported by Firefox and what is not?
What can cause problems?
Thanks in advance.
Any news?
Whiteboard: [necko-backlog]
Hi there!

Our solution is to change the value in about:config "network.dns.get-ttl" to false

regards
Rene
Whiteboard: [necko-backlog] → [necko-backlog][proxy]
See Also: → 1219935
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: -- → P1
Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258
Priority: P1 → P3

Bulk-downgrade of unassigned, >=3 years untouched DOM/Storage bug's priority.

If you have reason to believe this is wrong, please write a comment and ni :jstutte.

Severity: normal → S4
Priority: P3 → P5
You need to log in before you can comment on or make changes to this bug.