Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 30 users
Status: Verified
Owner:
User never visited
Closed: Oct 2014
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux, Chrome, Mac
Pri: 1
Type: Feature

Blocked on:
issue 84047



Sign in to add a comment
Non-Windows platforms: WPAD (proxy autodetect discovery) does not test DHCP
Project Member Reported by eroman@chromium.org, Aug 5 2009 Back to list
Chromium's implementation of WPAD is fairly limited, and only tests DNS for 
"wpad".

Really, DHCP should be tried first (by sending an INFORM message for option 
252).

Internet Explorer does this.

Chromium and Firefox however do not support it.

This bug isn't too severe, in that users can workaround it by manually 
entering the network's PAC location (whatever would have been returned by 
the 252) as a custom URL in the proxy settings.

But it is surely an inconvenience for setups relying on it.
 
the corresponding bug for Firefox is:
https://bugzilla.mozilla.org/show_bug.cgi?id=356831
Labels: -Area-Misc Area-BrowserBackend Mstone-5
Status: Assigned
Not sure what the anticipated timeline for this work is, but it seems like it should 
not block a 4.0 release.
Comment 3 by eroman@chromium.org, Oct 13 2009
Labels: -Pri-2 Pri-3
Status: WontFix
I will close this as WontFix for now.

I wanted there to be a bug on record for this, but don't intend for it to be addressed any time soon.

Other browsers including Firefox don't support this either, and it hasn't been significant for compatibility.
Labels: -Area-BrowserBackend Area-Internals
In my case, I informed my admistrator and he give me a URL to place in "LAN settings". In Google chrome, click on "Customize and Control Google Chrome" icon, select "Option", click on "Under the Hood", the "Internet Properties" page will pop up. Click on "Connections" tab, click on "LAN Settins" button, tick on "Use automatic configuration script" and type in the URL that your admistrator give you. 

If your adminstrator don't give you the path/URL "wpad.dat", I am afraid this suggestion won't me meaningful. 

Note that in my case, I need to do this everytime I reboot because some login script will reset the whole thing again. But I am OK with that, it might not be OK for "general users". This works for FireFox and Safari as well.

Use Configuration Script solving DHCP.JPG
102 KB View Download
Comment 6 by eroman@chromium.org, Aug 12 2010
Thanks for the feedback cheewen.chan, however I am not sure I understand what you are suggesting.

Entering an explicit URL to the wpad.dat file as you are doing should be fine, and work for both Chrome and Firefox.

The fact that your login script clears that on reboot must be frustrating. One workaround is to override use of the system proxy settings by editing your shortcut to Chrome and adding this command line flag:

  --proxy-pac-url=http://prefix.company.internal/wpad.dat


Adding support for DHCP would certainly be nice, but it isn't a priority right now.
Guys, i know this is marked as "won't fix" and deemed non-critical, but this sort of thing is a killer for using alternative browsers in the workplace.  If you can't do DHCP autoconfig, you need to either

- deal with an autoconfig URL which may/may not always be accessible (or correct!) for the network your roaming user is plugged into
- have the user manually configure proxy settings when they move from network to network.
- deal with DNS auto detect, and rely on fixing the WPAD dns breakage by default in Windows 2008 DNS to BLOCK wpad queries on every DNS server install unless it is manually fixed

DHCP easily falls back to direct access and easily automatically picks up the correct settings for the local network.

Using a URL will work fine for non-roaming users, for those with laptops who move from corporate network to corporate network, it is broken.
Comment 8 by eroman@chromium.org, Dec 23 2010
Labels: -Mstone-5 Mstone-X
Status: Available
jethro: I had closed this bug on the basis that it wasn't going to be fixed for version 5 of Chrome. I'll change the status to available since I agree this would be a good feature to have (We just don't have a current timeline on doing this).

Glenn: Have other enterprise users been asking for this feature?
Cheers for the timely response.  On my network its a major pain as "the other" browsers other than IE (primarily Chrome and Firefox) just generate support calls when they don't work, or when the user logs into another network (after we've configured to make them work locally), and then they don't work.

I suspect there's a fair number of corporate types out there with mandatory proxy use who rule out anything other than IE for this reason amongst others.

Its the death by a thousand paper-cuts thing, all the little issues add up....


I'm pretty sure there was code submitted to the mozilla project that never got checked in, under the relevant bug in mozilla (i followed the link listed above).
Hmmm, this does seem valuable.  I haven't heard any specific requests for this, but it seems to affect anyone who moves Chrome from network to network.

That said, we should probably add support for WPAD via DHCP.
Comment 11 Deleted
Comment 12 by Deleted ...@, Jan 6 2011
As an enterprise user, I'd like to add support for fixing/implementing support for DHCP as the first method for locating the WPAD configuration file. At my company we use a multi-site, hierarchical web proxy model primarily for two purposes; first, to route users to a geographically local proxy for performance and bandwidth usage considerations, and second to even the load across our internet-connected web proxy devices. To accomplish this we utilize location-aware load balancing to direct users to a local web server to retrieve a location-specific version of the WPAD configuration file. This is a fairly complex configuration to maintain across >10 widely dispersed locations, and is flawed since the load balancing solution is limited in its ability to determine user locations (it is not very granular). The proxy devices service both end-user web access and application web access, as well as B2B socks-based traffic. Legacy configuration on application servers make it difficult to reconfigure these servers to segregate user and application traffic on the proxy devices. We would like to use DHCP to replace our DNS-based solution for locating the WPAD configuration file, as all user desktops are configured to use DHCP. DHCP scopes are easily mapped to specific geographic locations which would enable more granular routing and load balancing. Unfortunately we cannot move forward
with this solution because of this bug (and the same bug in Mozilla Firefox). We would greatly appreciate this bug being resolved in a not-too-distant release. Thank
you.

Labels: -Type-Bug -Pri-3 -Size-Medium -Mstone-X Type-Feature Pri-2
Status: Untriaged
Well, that confirms it -- we have enterprise requests for this feature :)

Setting this to untriaged so the right triager will pick it up and put it in the right pipeline.
Labels: Internals-Network
Hey Glenn,

Does anyone on the Enterprise team have time to work on this?
Labels: Feature-Enterprise
Hey Glenn,

Does anyone on the Enterprise team have time to work on this?
If I understand the request correctly, this is a network-stack change, not a policy change.
Labels: Mstone-X
Status: Available
Comment 19 by joi@chromium.org, Feb 16 2011
Status: Assigned
I've started researching what it will take to fix this bug, but haven't started implementation yet.

Not sure it should be part of this bug or a separate one, but I noticed that our implementation is not only limited in that it only tests DNS, but also that it only tests the specific DNS name 'wpad' whereas the standard seems to indicate that if your host's DNS name is e.g. host.subdomain.foo.blat.com you should test, in order, wpad.subdomain.foo.blat.com, wpad.foo.blat.com, and wpad.blat.com.  If anybody knows the history of why we test only 'wpad' (it may be better?) I'd love to know.
@joi: comment #19 isn't related to this issue.

I can give an answer, but if you want to discuss it more broadly please do so on a different bug thread.

Chrome intentionally does not follow the specification for WPAD when it comes to DNS devolution.
Neither does Firefox for that matter.

The concern is regarding security: If you aren't extremely careful, then using the DNS devolution scheme outlined by the IETF draft, it is easy cross outside organizational boundaries and auto-detect external sites like "wpad.com" or "wpad.org.uk". Of course this is bad since it gives an attacker control over your web traffic. Historically this has been an issue.

To guard against such attacks, one could  test for top level domains (TLDs), and prevent fallback to eTLD+1 hosts. Conceptually this would work, however it is still fragile. Keep in mind that TLDs can change over time, and that in Chrome they are identified using a static registry which is shipped with the binary. That means whenever a new TLD is introduced, users would be vulnerable to this class of attack until the browser was updated to recognize that TLD.

So instead, the approach taken by Chrome is to just call getaddrinfo("wpad"). Implicitly this means we will use the client's DNS suffix search path. It is far easier for organizations to maintain the suffix search path in a safe way, and prevent jumping outside of the corporate boundary.

The current approach is a good tradeoff which is used widely. I don't think we should change it unless there is something to be gained in doing so. If you know of any user complaints regarding our lack of fallback let me  know.

Side-note: I will add comments to the source code to mention this issue for future readers of the source.
Comment 21 by joi@chromium.org, Feb 24 2011
I've done some research on this bug, and had discussions with eroman and wtc about it.

The most important findings are:

- It seems the only safe course of action is to reuse the local DHCP daemon.  It would have been fairly straightforward to implement a stand-alone DHCP client but the protocol kind of assumes a state machine between host and server, and throwing an extra client in there could confuse one end or the other, see e.g. http://www.net.princeton.edu/multi-dhcp-one-interface-handling.html

- There are documented APIs on Windows (DhcpRequestParams) and Mac OS X (DHCPInfoGetOptionData) that can be used to talk to the local DHCP daemon. On Linux, dhcpd seems to be prevalent (used e.g. on Ubuntu and by ChromeOS) but so far I haven't found a good way to ask it for the proxy auto-detect DHCP option (252) even though it has an API called OMAP.

My plan is:
a) Implement support on Windows using DhcpRequestParams.
b) Implement support on Mac using DHCPInfoGetOptionData.
c) Talk to CrOS folks to see if they know ways to get the option from dhcpd. If they do, we can add support for vanilla dhcpd; if they don't, we can evaluate whether to add support on CrOS only (to begin with) with a modified dhcpd.

All implementations will initially be behind a flag, and the DHCP lookups will be done serially, before we fall back to DNS.  Later, we will do DHCP and DNS in parallel to improve performance, then remove the flag.
Please implement this feature!

I use my notebook in many places, and many of them uses DHCP to inform PAC file.

It´s easier to keep using Internet Explorer, which can handle this, than change Chrome configuration by hand every time i change to a new network...
 Issue 39971  has been merged into this issue.
 Issue 55355  has been merged into this issue.
Project Member Comment 25 by bugdroid1@chromium.org, May 17 2011
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=85646

------------------------------------------------------------------------
r85646 | joi@chromium.org | Tue May 17 10:29:05 PDT 2011

Changed paths:
 A http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/dhcp_proxy_script_fetcher.cc?r1=85646&r2=85645&pathrev=85646
 A http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/dhcp_proxy_script_fetcher.h?r1=85646&r2=85645&pathrev=85646
 M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_script_fetcher.h?r1=85646&r2=85645&pathrev=85646
 A http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/dhcp_proxy_script_fetcher_win.cc?r1=85646&r2=85645&pathrev=85646
 M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/net_error_list.h?r1=85646&r2=85645&pathrev=85646
 A http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/mock_proxy_script_fetcher.h?r1=85646&r2=85645&pathrev=85646
 A http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/dhcp_proxy_script_fetcher_factory_unittest.cc?r1=85646&r2=85645&pathrev=85646
 A http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/dhcp_proxy_script_fetcher_factory.h?r1=85646&r2=85645&pathrev=85646
 A http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/dhcpcsvc_init_win.h?r1=85646&r2=85645&pathrev=85646
 M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_service.cc?r1=85646&r2=85645&pathrev=85646
 M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/init_proxy_resolver_unittest.cc?r1=85646&r2=85645&pathrev=85646
 M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/init_proxy_resolver.h?r1=85646&r2=85645&pathrev=85646
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/net/proxy_service_factory.cc?r1=85646&r2=85645&pathrev=85646
 A http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/dhcp_proxy_script_fetcher_factory.cc?r1=85646&r2=85645&pathrev=85646
 A http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/mock_proxy_script_fetcher.cc?r1=85646&r2=85645&pathrev=85646
 A http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/dhcp_proxy_script_fetcher_win_unittest.cc?r1=85646&r2=85645&pathrev=85646
 A http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/dhcp_proxy_script_fetcher_win.h?r1=85646&r2=85645&pathrev=85646
 M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/net_log_event_type_list.h?r1=85646&r2=85645&pathrev=85646
 M http://src.chromium.org/viewvc/chrome/trunk/src/net/net.gyp?r1=85646&r2=85645&pathrev=85646
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/net/connection_tester.cc?r1=85646&r2=85645&pathrev=85646
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/chrome_switches.cc?r1=85646&r2=85645&pathrev=85646
 M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_script_fetcher_impl.h?r1=85646&r2=85645&pathrev=85646
 A http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/dhcp_proxy_script_adapter_fetcher_win_unittest.cc?r1=85646&r2=85645&pathrev=85646
 M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/init_proxy_resolver.cc?r1=85646&r2=85645&pathrev=85646
 A http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/dhcp_proxy_script_adapter_fetcher_win.h?r1=85646&r2=85645&pathrev=85646
 M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_service_unittest.cc?r1=85646&r2=85645&pathrev=85646
 M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_service.h?r1=85646&r2=85645&pathrev=85646
 A http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/dhcp_proxy_script_adapter_fetcher_win.cc?r1=85646&r2=85645&pathrev=85646
 A http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/dhcpcsvc_init_win.cc?r1=85646&r2=85645&pathrev=85646
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/chrome_dll.gypi?r1=85646&r2=85645&pathrev=85646
 M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_script_fetcher_impl.cc?r1=85646&r2=85645&pathrev=85646
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/chrome_switches.h?r1=85646&r2=85645&pathrev=85646

Adds support for the DHCP portion of the WPAD (proxy auto-discovery) protocol.

This is Windows-only for now, and is disabled by default.  Start
Chrome with the flag --enable-dhcp-wpad to enable the feature.  See
discussion in comment on DhcpProxyScriptFetcherFactory for why this
needs to be done in a per-platform way rather than cross-platform.
The code is factored so that adding other platform implementations
will be straight forward.

Most of the implementation is stand-alone and extends the
ScriptProxyFetcher class hierarchy (and makes its interface slightly
more generic).  The integration point into existing code is in
InitProxyResolver, which previously handled fallback from DNS
auto-detect to custom PAC URL and now does fallback from DHCP to DNS
to custom PAC URL.

BUG= 18575 
TEST=net_unittests has good coverage for the new and changed code, but
manual tests on a network with a PAC URL configured in DHCP are also
needed.

Review URL: http://codereview.chromium.org/6831025
------------------------------------------------------------------------
Comment 26 by joi@chromium.org, May 17 2011
If anybody on this bug tests on Windows with the --enable-dhcp-wpad flag enabled (on either a tip-of-tree build after r85646 or a Canary build tomorrow or later) then please let me know how it goes by emailing me directly.
Project Member Comment 27 by bugdroid1@chromium.org, May 17 2011
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=85648

------------------------------------------------------------------------
r85648 | joi@chromium.org | Tue May 17 10:55:35 PDT 2011

Changed paths:
 D http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/dhcp_proxy_script_fetcher_win_unittest.cc?r1=85648&r2=85647&pathrev=85648
 D http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/dhcp_proxy_script_fetcher_win.h?r1=85648&r2=85647&pathrev=85648
 M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/net_log_event_type_list.h?r1=85648&r2=85647&pathrev=85648
 D http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/dhcp_proxy_script_fetcher.cc?r1=85648&r2=85647&pathrev=85648
 D http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/dhcp_proxy_script_fetcher.h?r1=85648&r2=85647&pathrev=85648
 M http://src.chromium.org/viewvc/chrome/trunk/src/net/net.gyp?r1=85648&r2=85647&pathrev=85648
 M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_script_fetcher.h?r1=85648&r2=85647&pathrev=85648
 D http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/dhcp_proxy_script_fetcher_win.cc?r1=85648&r2=85647&pathrev=85648
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/net/connection_tester.cc?r1=85648&r2=85647&pathrev=85648
 M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/net_error_list.h?r1=85648&r2=85647&pathrev=85648
 D http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/mock_proxy_script_fetcher.h?r1=85648&r2=85647&pathrev=85648
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/chrome_switches.cc?r1=85648&r2=85647&pathrev=85648
 M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_script_fetcher_impl.h?r1=85648&r2=85647&pathrev=85648
 D http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/dhcp_proxy_script_fetcher_factory.h?r1=85648&r2=85647&pathrev=85648
 D http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/dhcp_proxy_script_adapter_fetcher_win_unittest.cc?r1=85648&r2=85647&pathrev=85648
 M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/init_proxy_resolver.cc?r1=85648&r2=85647&pathrev=85648
 D http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/dhcpcsvc_init_win.h?r1=85648&r2=85647&pathrev=85648
 D http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/dhcp_proxy_script_adapter_fetcher_win.h?r1=85648&r2=85647&pathrev=85648
 M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_service.cc?r1=85648&r2=85647&pathrev=85648
 M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_service_unittest.cc?r1=85648&r2=85647&pathrev=85648
 M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_service.h?r1=85648&r2=85647&pathrev=85648
 D http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/dhcp_proxy_script_adapter_fetcher_win.cc?r1=85648&r2=85647&pathrev=85648
 M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/init_proxy_resolver_unittest.cc?r1=85648&r2=85647&pathrev=85648
 M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/init_proxy_resolver.h?r1=85648&r2=85647&pathrev=85648
 D http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/dhcpcsvc_init_win.cc?r1=85648&r2=85647&pathrev=85648
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/net/proxy_service_factory.cc?r1=85648&r2=85647&pathrev=85648
 D http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/dhcp_proxy_script_fetcher_factory.cc?r1=85648&r2=85647&pathrev=85648
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/chrome_dll.gypi?r1=85648&r2=85647&pathrev=85648
 M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_script_fetcher_impl.cc?r1=85648&r2=85647&pathrev=85648
 D http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/mock_proxy_script_fetcher.cc?r1=85648&r2=85647&pathrev=85648
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/chrome_switches.h?r1=85648&r2=85647&pathrev=85648

Revert 85646 - Adds support for the DHCP portion of the WPAD (proxy auto-discovery) protocol.

This is Windows-only for now, and is disabled by default.  Start
Chrome with the flag --enable-dhcp-wpad to enable the feature.  See
discussion in comment on DhcpProxyScriptFetcherFactory for why this
needs to be done in a per-platform way rather than cross-platform.
The code is factored so that adding other platform implementations
will be straight forward.

Most of the implementation is stand-alone and extends the
ScriptProxyFetcher class hierarchy (and makes its interface slightly
more generic).  The integration point into existing code is in
InitProxyResolver, which previously handled fallback from DNS
auto-detect to custom PAC URL and now does fallback from DHCP to DNS
to custom PAC URL.

BUG= 18575 
TEST=net_unittests has good coverage for the new and changed code, but
manual tests on a network with a PAC URL configured in DHCP are also
needed.

Review URL: http://codereview.chromium.org/6831025

TBR=joi@chromium.org
Review URL: http://codereview.chromium.org/7019015
------------------------------------------------------------------------
Comment 28 by joi@chromium.org, May 17 2011
Relanded as r85661.
Project Member Comment 29 by bugdroid1@chromium.org, May 17 2011
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=85661

------------------------------------------------------------------------
r85661 | joi@chromium.org | Tue May 17 12:53:00 PDT 2011

Changed paths:
 A http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/dhcp_proxy_script_fetcher.cc?r1=85661&r2=85660&pathrev=85661
 A http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/dhcp_proxy_script_fetcher.h?r1=85661&r2=85660&pathrev=85661
 M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_script_fetcher.h?r1=85661&r2=85660&pathrev=85661
 A http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/dhcp_proxy_script_fetcher_win.cc?r1=85661&r2=85660&pathrev=85661
 M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/net_error_list.h?r1=85661&r2=85660&pathrev=85661
 A http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/mock_proxy_script_fetcher.h?r1=85661&r2=85660&pathrev=85661
 M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/dhcp_proxy_script_fetcher_factory_unittest.cc?r1=85661&r2=85660&pathrev=85661
 A http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/dhcp_proxy_script_fetcher_factory.h?r1=85661&r2=85660&pathrev=85661
 A http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/dhcpcsvc_init_win.h?r1=85661&r2=85660&pathrev=85661
 M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_service.cc?r1=85661&r2=85660&pathrev=85661
 M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/init_proxy_resolver_unittest.cc?r1=85661&r2=85660&pathrev=85661
 M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/init_proxy_resolver.h?r1=85661&r2=85660&pathrev=85661
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/net/proxy_service_factory.cc?r1=85661&r2=85660&pathrev=85661
 A http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/dhcp_proxy_script_fetcher_factory.cc?r1=85661&r2=85660&pathrev=85661
 A http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/mock_proxy_script_fetcher.cc?r1=85661&r2=85660&pathrev=85661
 A http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/dhcp_proxy_script_fetcher_win_unittest.cc?r1=85661&r2=85660&pathrev=85661
 A http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/dhcp_proxy_script_fetcher_win.h?r1=85661&r2=85660&pathrev=85661
 M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/net_log_event_type_list.h?r1=85661&r2=85660&pathrev=85661
 M http://src.chromium.org/viewvc/chrome/trunk/src/net/net.gyp?r1=85661&r2=85660&pathrev=85661
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/net/connection_tester.cc?r1=85661&r2=85660&pathrev=85661
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/chrome_switches.cc?r1=85661&r2=85660&pathrev=85661
 M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_script_fetcher_impl.h?r1=85661&r2=85660&pathrev=85661
 A http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/dhcp_proxy_script_adapter_fetcher_win_unittest.cc?r1=85661&r2=85660&pathrev=85661
 M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/init_proxy_resolver.cc?r1=85661&r2=85660&pathrev=85661
 A http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/dhcp_proxy_script_adapter_fetcher_win.h?r1=85661&r2=85660&pathrev=85661
 M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_service_unittest.cc?r1=85661&r2=85660&pathrev=85661
 M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_service.h?r1=85661&r2=85660&pathrev=85661
 A http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/dhcp_proxy_script_adapter_fetcher_win.cc?r1=85661&r2=85660&pathrev=85661
 A http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/dhcpcsvc_init_win.cc?r1=85661&r2=85660&pathrev=85661
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/chrome_dll.gypi?r1=85661&r2=85660&pathrev=85661
 M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_script_fetcher_impl.cc?r1=85661&r2=85660&pathrev=85661
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/chrome_switches.h?r1=85661&r2=85660&pathrev=85661

Adds support for the DHCP portion of the WPAD (proxy auto-discovery) protocol.

This is Windows-only for now, and is disabled by default.  Start
Chrome with the flag --enable-dhcp-wpad to enable the feature.  See
discussion in comment on DhcpProxyScriptFetcherFactory for why this
needs to be done in a per-platform way rather than cross-platform.
The code is factored so that adding other platform implementations
will be straight forward.

Most of the implementation is stand-alone and extends the
ScriptProxyFetcher class hierarchy (and makes its interface slightly
more generic).  The integration point into existing code is in
InitProxyResolver, which previously handled fallback from DNS
auto-detect to custom PAC URL and now does fallback from DHCP to DNS
to custom PAC URL.

BUG= 18575 
TEST=net_unittests has good coverage for the new and changed code, but
manual tests on a network with a PAC URL configured in DHCP are also
needed.

Original commit r85646.
Reverted (test failures on some release bots) r85648.
Will reland with fix.

Review URL: http://codereview.chromium.org/6831025
------------------------------------------------------------------------
Comment 30 Deleted
Project Member Comment 32 by bugdroid1@chromium.org, May 24 2011
Comment 33 by joi@chromium.org, May 24 2011
This feature is now on by default on trunk, implemented only for Windows so far. It should be available on Canary builds starting with tonight's/tomorrow morning's build (it should have version number 13.0.775.0 or greater).

Please test it if you're interested in this bug, and please enable user experience metrics when you install Chrome.  We will evaluate just before the M13 branch point (Monday May 30th) based on the available user experience metrics, whether to keep the feature on by default on the M13 branch.
Just tested the most recent canary build here (13.0.775) and again DHCP
auto-detect is working fine. :)
Comment 35 by joi@chromium.org, May 27 2011
Blockedon: 84047
We've decided to turn this feature off by default on the M13 branch.  I will turn it back on by default on the dev channel right after the M13 branch has been created.  See issue 84047 for details.
Project Member Comment 36 by bugdroid1@chromium.org, May 27 2011
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=87047

------------------------------------------------------------------------
r87047 | joi@chromium.org | Fri May 27 11:14:00 PDT 2011

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/net/connection_tester.cc?r1=87047&r2=87046&pathrev=87047
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/net/proxy_service_factory.cc?r1=87047&r2=87046&pathrev=87047
 M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/dhcp_proxy_script_fetcher_factory.cc?r1=87047&r2=87046&pathrev=87047
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/chrome_switches.cc?r1=87047&r2=87046&pathrev=87047
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/chrome_switches.h?r1=87047&r2=87046&pathrev=87047
 M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/dhcp_proxy_script_fetcher_factory_unittest.cc?r1=87047&r2=87046&pathrev=87047
 M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/dhcp_proxy_script_fetcher_factory.h?r1=87047&r2=87046&pathrev=87047

Revert 86422 - Make DHCP WPAD on by default.

Reason: Turning off for M13 branch based on some concerns from user experience metrics. Will re-enable after M13 branch point.

BUG= 18575 ,84047
TEST=Run Chrome on Windows without any flags. Enable auto-detect in proxy configuration. Net log should show attempts to auto-detect via DHCP.

Review URL: http://codereview.chromium.org/7082004
------------------------------------------------------------------------
Project Member Comment 37 by bugdroid1@chromium.org, Jun 17 2011
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=89486

------------------------------------------------------------------------
r89486 | joi@chromium.org | Fri Jun 17 08:30:58 PDT 2011

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/net/connection_tester.cc?r1=89486&r2=89485&pathrev=89486
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/net/proxy_service_factory.cc?r1=89486&r2=89485&pathrev=89486
 M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/dhcp_proxy_script_fetcher_factory.cc?r1=89486&r2=89485&pathrev=89486
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/chrome_switches.cc?r1=89486&r2=89485&pathrev=89486
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/chrome_switches.h?r1=89486&r2=89485&pathrev=89486
 M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/dhcp_proxy_script_fetcher_factory_unittest.cc?r1=89486&r2=89485&pathrev=89486
 M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/dhcp_proxy_script_fetcher_factory.h?r1=89486&r2=89485&pathrev=89486

Revert 87047 - Revert 86422 - Make DHCP WPAD on by default.

Reason: Turning back on for trunk to collect data as performance worries are addressed.

BUG= 18575 ,84047
TEST=Run Chrome on Windows without any flags. Enable auto-detect in proxy configuration. Net log should show attempts to auto-detect via DHCP.

Review URL: http://codereview.chromium.org/7167016
------------------------------------------------------------------------
Project Member Comment 38 by bugdroid1@chromium.org, Jun 19 2011
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=89629

------------------------------------------------------------------------
r89629 | cevans@chromium.org | Sun Jun 19 15:37:01 PDT 2011

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/net/connection_tester.cc?r1=89629&r2=89628&pathrev=89629
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/net/proxy_service_factory.cc?r1=89629&r2=89628&pathrev=89629
 M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/dhcp_proxy_script_fetcher_factory.cc?r1=89629&r2=89628&pathrev=89629
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/chrome_switches.cc?r1=89629&r2=89628&pathrev=89629
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/chrome_switches.h?r1=89629&r2=89628&pathrev=89629
 M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/dhcp_proxy_script_fetcher_factory_unittest.cc?r1=89629&r2=89628&pathrev=89629
 M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/dhcp_proxy_script_fetcher_factory.h?r1=89629&r2=89628&pathrev=89629

Revert 89486 - Revert 87047 - Revert 86422 - Make DHCP WPAD on by default.

Reason: Turning back on for trunk to collect data as performance worries are addressed.

BUG= 18575 ,84047
TEST=Run Chrome on Windows without any flags. Enable auto-detect in proxy configuration. Net log should show attempts to auto-detect via DHCP.

Review URL: http://codereview.chromium.org/7167016

TBR=joi@chromium.org

NOTE: I'll roll it back in if it turns out this wasn't the problem.
Review URL: http://codereview.chromium.org/7200025
------------------------------------------------------------------------
Project Member Comment 39 by bugdroid1@chromium.org, Jun 20 2011
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=89633

------------------------------------------------------------------------
r89633 | cevans@chromium.org | Sun Jun 19 17:28:21 PDT 2011

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/net/connection_tester.cc?r1=89633&r2=89632&pathrev=89633
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/net/proxy_service_factory.cc?r1=89633&r2=89632&pathrev=89633
 M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/dhcp_proxy_script_fetcher_factory.cc?r1=89633&r2=89632&pathrev=89633
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/chrome_switches.cc?r1=89633&r2=89632&pathrev=89633
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/chrome_switches.h?r1=89633&r2=89632&pathrev=89633
 M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/dhcp_proxy_script_fetcher_factory_unittest.cc?r1=89633&r2=89632&pathrev=89633
 M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/dhcp_proxy_script_fetcher_factory.h?r1=89633&r2=89632&pathrev=89633

Revert 89629 - Revert 89486 - Revert 87047 - Revert 86422 - Make DHCP WPAD on by default.

Reason: Turning back on for trunk to collect data as performance worries are addressed.

BUG= 18575 ,84047
TEST=Run Chrome on Windows without any flags. Enable auto-detect in proxy configuration. Net log should show attempts to auto-detect via DHCP.

Review URL: http://codereview.chromium.org/7167016

TBR=joi@chromium.org

NOTE: I'll roll it back in if it turns out this wasn't the problem.
Review URL: http://codereview.chromium.org/7200025

TBR=cevans@chromium.org
Review URL: http://codereview.chromium.org/7204024
------------------------------------------------------------------------
Comment 40 by scott...@gmail.com, Jun 29 2011
Cc: rohi...@chromium.org scott...@gmail.com
Comment 41 by joi@chromium.org, Jul 6 2011
 Issue 39165  has been merged into this issue.
Comment 42 by joi@chromium.org, Aug 3 2011
Cc: joi@chromium.org
Labels: -OS-All OS-Chrome OS-Linux OS-Mac
Owner: ----
Summary: Non-Windows platforms: WPAD (proxy autodetect discovery) does not test DHCP (was: NULL)
Cc: -rohi...@chromium.org
Blockedon: -chromium:84047 chromium:84047
Status: Available
Comment 45 by joi@chromium.org, Aug 9 2012
Blockedon: -chromium:84047
Project Member Comment 46 by bugdroid1@chromium.org, Nov 14 2012
The following revision refers to this bug:
    http://goto.ext.google.com/viewvc/chrome-internal?view=rev&revision=15206

------------------------------------------------------------------------
r15206 | joi@google.com | 2011-05-24T14:01:04.153926Z

------------------------------------------------------------------------
Project Member Comment 47 by bugdroid1@chromium.org, Mar 10 2013
Labels: -Area-Internals -Internals-Network -Feature-Enterprise Cr-Internals Cr-Internals-Network Cr-Enterprise
This issue still exists on Chrome 27.0.1453.110.

Chrome is not able to work correctly with automatically configured proxies.

Chrome works fine if 1) proxy is configured manually or 2) proxy is configured automatically AND a configuration URL is provided. It doesn't do automatic discovery.
Comment 49 by Deleted ...@, Nov 14 2013
WPAD stop in Chrome version 31.0.1650.48 in Win 8.1, IE 11 is OK

ChromeWpad.jpg
83.5 KB View Download
Eric, any clues about #49? Did something regress?
I think this is a regression on windows in m31 due to a bug in the quick
check logic. I'll enter a separate p0 bug to address it.
 https://crbug.com/318730  for the Windows regression in M31
Comment 53 Deleted
Comment 54 by Deleted ...@, Nov 15 2013
link #52 provide doesnt seem to work
do you think we can an update anytime soon to correct this ?
Comment 55 by roy...@google.com, Nov 15 2013
Fixed link:  http://crbug.com/318730 

Status: Fixed
Please open a new bug if there are any further issues with proxy auto discovery.
Status: Untriaged
This isn't fixed. The issue mentioned fixed in #55 was a regression in how DHCP-based WPAD worked on Windows. The focus of this bug is supporting DHCP-based WPAD on non-Windows platforms. Reopening.
Labels: Enterprise-Triaged
Owner: saswat@chromium.org
Status: Available
Saswat to prioritize FR.
At our organisation, we have a requirement for this feature to support the rollout of 1000's of chrome devices. 

Can we please have an indication on the timeframe for this. 

THanks
Comment 60 Deleted
Cc: krishna...@chromium.org krisr@chromium.org pstew@chromium.org steve...@chromium.org chron@chromium.org
 Issue 321723  has been merged into this issue.
From comment #21 and current implementation, we'd like to try to go out to system DHCP daemons rather than spawning our own in Chrome to do queries.

On ChromeOS, do we have a dbus interface to dhcpd or equivalent that Chrome could call?
Actually, looks like we already are supposed to support DHCP-discovered WPAD on ChromeOS.

See https://code.google.com/p/chromium/issues/detail?id=253915 and dhcp_proxy_script_fetcher_chromeos

#59: Have you confirmed that proxy auto-discovery is enabled (via enterprise policy or other means) for your network? This is not enabled by default.

Will hopefully get to a network later today that does WPAD-over-DHCP to confirm that this works as expected.


 this already on ChromeOS. See dhcp_proxy_script_
#59: If you turn on proxy auto-discovery manually for your network on a ChromeOS device, do you see DHCP WPAD working?

Quick instructions:
  - go to chrome://settings
  - Select "Allow proxies for shared networks"
  - Choose the current network
  - Select the "proxy" tab in the network settings dialog
  - Select the "Automatic Proxy Configuration' radio button

I want to diagnose whether this is an underlying problem with Chrome-on-ChromeOS, ChromeOS's DHCP client, or network configuration.

Feel free to contact me directly at cbentzel@chromium.org if you don't want to post some of the details on this bug.
we have pushed, from CPanel, to our users with "Always auto detect the proxy" settings.  From Chrome://system -> Network-Status, I can see the setting from DHCP scope applied to the device.  However, under chrome://settings -> Proxy, Current setting is "Use Direct Connection".  
Thanks for the additional details #65
Cc: pneubeck@chromium.org
+pneubeck@ who has a better understanding of how proxies work in Chrome, and a much better understanding of how ONC policies work.

Comment 68 by edoan@chromium.org, Jun 10 2014
Labels: Hotlist-Enterprise
Labels: -Pri-2 Pri-1
Labels: -Mstone-X M-38
Tested in ChromeOS R36 and it's still not fixed.  
Comment 72 by joi@chromium.org, Jun 16 2014
Cc: -joi@chromium.org
Labels: -Hotlist-Enterprise
Hi, are there any updates and how real is this for M38?
Comment 75 by edoan@chromium.org, Aug 27 2014
M38 has branched. Are we now looking at this for R39?
Owner: pneubeck@chromium.org
Comment 77 by alu...@google.com, Sep 5 2014
Just tested this with  38.02125.26 beta and  R37 stable and it appears to be working.

1) Under Chrome:/settings -> Proxy Automatic proxy configuration is selected 
2) Observed in proxy logs that the PAC file was being respected.

See screen shots. 
Screenshot 2014-09-05 at 4.07.25 PM.png
254 KB View Download
wiresharkDhcpAck_WPAD.png
85.3 KB View Download
Screenshot 2014-09-05 at 4.07.00 PM.png
128 KB View Download
@woolworths.com.au, can you confirm that WPAD works for you as expected with >=R37?
Comment 79 by alu...@google.com, Sep 26 2014
Per D...@woolworths.com.au now working on Chromebook with R37 stable and R38 beta. (9/14/14)
Status: Fixed
Closing as fixed according to comments #77 and #79.
Please reopen if you still run into issues.
Status: Verified
Verified via #77 and #79. Also verified with R38-6158.62.0/38.0.2125.105 on winky.
Comment 82 by Deleted ...@, Jul 9 2015
tried on google chrome Version 43.0.2357.132 m, able to detect the pac file as below:

Effective proxy settings

PAC script: http://qqqq.qqqq.qqqq/accelerated_pac_base.pac
Source: SYSTEM
Original proxy settings

Auto-detect
Source: SYSTEM

but the web pages loading is very slow, and IE is working fine, page loading is fast
Sign in to add a comment