ProxyResolverWinHttp no longer created?
Marshall Greenblatt
I'm attempting to better understand ProxyService as it relates to http://crbug.com/40797. That bug describes a situation on Windows where ProxyResolverWinHttp causes delays in resource loading when "Automatically detect settings" is true. Starting after eroman's refactoring of ProxyService this bug no longer reproduces. Currently (as of rev 61327) it seems that ProxyResolverFactoryForNonV8::CreateProxyResolver() is not being called, which means the ProxyResolverWinHttp instance is not being created. This is true for both Chromium and test_shell. Is this the expected behavior?
Thanks,
Marshall
Eric Roman
Proxy autodetect is not supported in TestShell (or in single-process
Chrome for that matter).
On Windows we have a convenience fallback to WinHTTP (system library)
when you are running in single process mode, but this isn't really a
supported mode. You can see larger delays when using this
implementation, as it is less performant (most notably it doesn't
cache DNS resolves within a script, which really slows things down).
You could in theory run Chromium's proxy resolver in TestShell, but
you would have to work around V8 being non-thread safe.
One way would be to put locks around all the webkit entry points into
V8 (yuck!), or you could make the proxy resolver single-threaded and
have it post tasks over to the renderer's single thread (this will
also make for bad performance).
Cheers.
Marshall Greenblatt
On Fri, Oct 8, 2010 at 2:32 PM, Eric Roman <ero...@chromium.org> wrote:
Hi Marshall,
Proxy autodetect is not supported in TestShell (or in single-process
Chrome for that matter).
On Windows we have a convenience fallback to WinHTTP (system library)
when you are running in single process mode, but this isn't really a
supported mode. You can see larger delays when using this
implementation, as it is less performant (most notably it doesn't
cache DNS resolves within a script, which really slows things down).
You could in theory run Chromium's proxy resolver in TestShell, but
you would have to work around V8 being non-thread safe.
One way would be to put locks around all the webkit entry points into
V8 (yuck!), or you could make the proxy resolver single-threaded and
have it post tasks over to the renderer's single thread (this will
also make for bad performance).
Thanks for the explanation, that makes a lot of sense and addresses issue #2 (see below).
Issue #1:
I'm currently running Chromium with the --winhttp-proxy-resolver flag in order to test similar proxy behavior between Chromium and test_shell. I notice that both Chromium (with the --winhttp-proxy-resolver flag) and test_shell are calling ProxyConfigServiceWin::GetCurrentProxyConfig in order to retrieve the proxy configuration.
On one Windows 7 64bit machine, I have "Automatically detect settings" checked under Internet Options but the call to WinHttpGetIEProxyConfigForCurrentUser in ProxyConfigServiceWin::GetCurrentProxyConfig, while succeeding, is not setting the fAutoDetect member of WINHTTP_CURRENT_USER_IE_PROXY_CONFIG. As a result, ProxyConfig::auto_detect() returns false and Chromium is never attempting to resolve proxy requests using ProxyResolverWinHttp. This isn't actually a problem for me, I just have no idea what's causing it on this particular machine.
Issue #2:
On other Windows machines WinHttpGetIEProxyConfigForCurrentUser correctly sets the fAutoDetect member when "Automatically detect settings" is checked. As a result, ProxyConfig::auto_detect() returns true and this eventually results in a call to ProxyResolverWinHttp::GetProxyForURL() as expected. ProxyResolverWinHttp::GetProxyForURL() causes slow request loading times in both Chromium (with the --winhttp-proxy-resolver flag) and test_shell due to the synchronous execution of WinHttpGetProxyForUrl.
For issue #2, I see two potential solutions:
A. Make the V8-based proxy implementation work in test_shell. From your response this seems like a lot of work for limited gain.
B. Always have ProxyConfig::auto_detect() return false for test_shell. This seems like a reasonable approach since, if the user wants a proxy, they can always manually configure one without hurting performance in the more common no-proxy use case.
Do you agree that B makes sense? If so, what do you think the best way to accomplish this would be?
Thanks,
Marshall
Eric Roman
There are competing libraries on windows to get at the proxy settings
(notably wininet and winhttp), and each has its own quirks.
You are probably tickling one of those issues (in fact I've seen some
pretty annoying bugs on win7 machines which required calling winhttp
from a background thead).
Lets take this off thread, I can show you where to poke around in the
registry to understand what the problem is.
>
> Issue #2:
>
> On other Windows machines WinHttpGetIEProxyConfigForCurrentUser correctly
> sets the fAutoDetect member when "Automatically detect settings" is checked.
> As a result, ProxyConfig::auto_detect() returns true and this eventually
> results in a call to ProxyResolverWinHttp::GetProxyForURL() as expected.
> ProxyResolverWinHttp::GetProxyForURL() causes slow request loading times in
> both Chromium (with the --winhttp-proxy-resolver flag) and test_shell due to
> the synchronous execution of WinHttpGetProxyForUrl.
>
> For issue #2, I see two potential solutions:
>
> A. Make the V8-based proxy implementation work in test_shell. From your
> response this seems like a lot of work for limited gain.
> B. Always have ProxyConfig::auto_detect() return false for test_shell. This
> seems like a reasonable approach since, if the user wants a proxy, they can
> always manually configure one without hurting performance in the more common
> no-proxy use case.
>
> Do you agree that B makes sense? If so, what do you think the best way to
> accomplish this would be?
Disabling proxy-autoconfig completely in TestShell sounds ok to me.
The downside of course is it may impact users of TestShell from a
compatibility standpoint (if they are expecting to be using the IE
settings).
On a positive note, if we do go this route we can then delete the mac
+ windows auxiliary proxy resolver implementations.
If you want to experiment with it, open up net/proxy/proxy_service.cc,
and search for the line "return new ProxyResolverWinHttp()". Replace
it by "return new ProxyResolverNull()" and you should be set.