Hm maybe an Internals>Network component would suit this report better?

Let's triage to the more specific proxy component.

Cc'ing 	eroman@ from  Issue 755537  for more inputs and help in further debugging of the attached log in C#1.

Hi
Any update on this bug please?
Kind Regards

Thanks for the log.

It looks like it hits the 2 second timeout, which is working as intended.

Workaround would be to provide the PAC URL directly rather than using auto-detect.

Comment #9 and #10 were deleted, but in response to some of the questions:

* There currently is no configuration option to increase the timeout. If we did change this, we would likely just want to change the global default. How many seconds does it take clients to download the PAC script?

* The consequence of increasing various timeouts around auto-detect is slowing down detection when there really is no PAC script to use. Although there is probably some leeway in doing so for DHCP-discovered scripts since there is a higher chance of it working than say DNS-discovered scripts.

* The most robust solution is to not use auto-detect, and just set an explicit PAC script for your machines. Auto-detect is slow. When using a explicit PAC script the timeout would be much higher (order of minutes), which in fact by many other metrics has the opposite problem (of taking too long to timeout when there are connectivity issues)...

To validate you can try fetching the PAC URL discovered by DHCP on a configuration that uses no proxy server, and see how long that takes (from the earlier analysis I think we determined that it was taking longer than 2 seconds and hence being cancelled).

One could make an argument to increase the DHCP timeout to a slightly higher threshold, say 4 seconds. But the first step is seeing what timeout would actually work for your use-case.

Thanks for the feedback.