Chrome loads slow when using --winhttp-proxy-resolver argument
Reported by
forcepoi...@gmail.com,
Jun 6 2018
|
||||
Issue description
UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.181 Safari/537.36
Example URL:
Any URL
Steps to reproduce the problem:
1. Install Chrome on fresh, clean Windows 7 x64 VM
2. Check the 'Automatically detect settings' under 'Internet Options > Connections > LAN Settings'
3. Add new host only network connection (if VM) or alternatively install VirtualBox or VM Workstation, that will automatically install host only network connection.
4. Run Chrome with --winhttp-proxy-resolver argument.
What is the expected behavior?
Chrome should load URL successfully in reasonable time.
What went wrong?
Chrome is stuck "Resolving Proxy" for up to a minute. Chrome eventually loads the webpage.
Did this work before? N/A
Chrome version: 66.0.3359.181 Channel: n/a
OS Version: 7
Flash Version:
Workarounds that were found:
1: Uncheck "Automatically detect settings" in Internet options
2. Do not use --winhttp-proxy-resolver argument
3. Use Internet Explorer to load a webpage first, and then Chrome will load normally. This workaround has only worked on a test environment, but does not work for customer environments experiencing same issue.
Forcepoint customers have confirmed that without Forcepoint product installed, running Chrome with --winhttp-proxy-resolver will still have issue.
Using chrome://net-internals/, we see that Effective proxy settings are Auto-detect, Source: SYSTEM. Chrome was not able to auto-detect the system proxy settings.
URL REQUESTS show:
t=10 [st=0] +REQUEST_ALIVE [dt=?]
--> has_upload = true
--> is_pending = true
--> load_flags = 0 (NORMAL)
--> load_state = 8 (RESOLVING_PROXY_FOR_URL)
--> method = "POST"
--> net_error = -1 (ERR_IO_PENDING)
--> status = "IO_PENDING"
--> url = "https://accounts.google.com/ListAccounts?gpsia=1&source=ChromiumAccountReconcilor,counter:0,load_time_ms:79&json=standard"
,
Jun 7 2018
,
Jun 7 2018
Unable to test this issue from TE end as this requires clean windows on VM and new host connection/Virtual box to test this issue. Hence adding TE-NeedsTriageHelp for further triaging from Internals>Network>Proxy team. Thanks!
,
Jun 7 2018
Thanks for the report Note that the --winhttp-proxy-resolver flag is unsupported/deprecated (Issue 644030). As we don't control the performance characteristics of WinHTTP's proxy resolving, nor want to invest more effort in supporting --winhttp-proxy-resolver, this is a WontFix. * Proxy Auto Detect (WPAD) is inherently a slow protocol, and also a security and privacy stumbling point (see for example https://www.us-cert.gov/ncas/alerts/TA16-144A). The best solution for your customers would be to avoid using it altogether and configure the proxy directly either using a PAC URL, or manual proxies, or offloading the decision to an extension. * If you have NetLogs showing a performance problem in Chrome's supported path for proxy auto-detect (without the --winhttp-proxy-resolver flag) I can take a look. * Your UA suggests use of Chrome 66. Note that in Chrome 67 we changed how fallback between proxy servers works to align with how WinHTTP was doing it. Do you still have a need for using --winhttp-proxy-resolver? Thanks
,
Jul 23
Sorry for the delayed response. Our Endpoint enforces the use of this flag as it fixed another issue where users were seeing "Waiting For Forcepoint Extension" hang. When we enforce this flag, that issue is no longer seen but now introduces the issue described in this bug report on some environments. Do you think that with Chrome 67, the "Waiting for Forcepoint Extension" issue is fixed? If that is the case, our Endpoint can stop the enforcement of the --winhttp-proxy-resolver flag with no issues.
,
Jul 31
@forcepointendpoint: Thanks for following-up! Yes, Endpoint should definitely shouldn't be adding --winhttp-proxy-resolver. We have been seeing some reports where Chrome mysteriously has this flag turned on, and it breaks a slew of other things including proxying of websockets, support for proxy extensions (as data: and file:// are no longer supported). I don't know what specific reason you were using --winhttp-proxy-resolver as a workaround for, however Chrome 67 addressed one of the biggest remaining use-cases for --winhttp-proxy-resolver ( Issue 680837 ) which was to match IE in NOT considering fallbacks on proxy protocol errors. If you have a specific use case for keeping --winhttp-proxy-resolver please follow-up with me separately or on Issue 680837 and we can work out a solution. |
||||
►
Sign in to add a comment |
||||
Comment 1 by davidben@chromium.org
, Jun 6 2018