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

net/proxy/dhcp_proxy_script_fetcher_factory.h

Index: net/proxy/dhcp_proxy_script_fetcher_factory.h
diff --git a/net/proxy/dhcp_proxy_script_fetcher_factory.h b/net/proxy/dhcp_proxy_script_fetcher_factory.h
new file mode 100644
index 0000000000000000000000000000000000000000..c80ed124a179721d7d8809bd3d006c76d81baf73
--- /dev/null
+++ b/net/proxy/dhcp_proxy_script_fetcher_factory.h
@@ -0,0 +1,65 @@
+// Copyright (c) 2011 The Chromium Authors. All rights reserved.
+// Use of this source code is governed by a BSD-style license that can be
+// found in the LICENSE file.
+
+#ifndef NET_PROXY_DHCP_SCRIPT_FETCHER_FACTORY_H_
+#define NET_PROXY_DHCP_SCRIPT_FETCHER_FACTORY_H_
+#pragma once
+
+#include "base/basictypes.h"
+#include "base/memory/singleton.h"
+#include "net/base/completion_callback.h"
+#include "net/url_request/url_request_context.h"
+
+namespace net {
+
+class DhcpProxyScriptFetcher;
+
+// Factory object (non-singleton) for creating the appropriate concrete base

[eroman, 2011/05/13 05:03:32]

What do you mean by non-singleton? This is in fact a singleton.

I would prefer it as a non-singleton, since we are trying to move away from
globals. Especially in the multi-profile world, it is increasingly important to
be able to configure things separately for different profiles, singletons make
that goal much harder.

[Jói, 2011/05/13 20:19:09]

I commented that way because you use it via static methods rather than
::GetInstance()->FooBar().  Guess it should have been just "Static factory for
..."

The option that the factory stores here is a command-line option, so it is
inherently global, which is why I preferred to keep it initialized via
BrowserMain.  Since you still disagree with initializing it there, I have made
the factory object non-static and moved its initialization to the two places
where it is used (connection_tester.cc and proxy_service_factory.cc).

+// class of DhcpProxyScriptFetcher for your operating system and settings.
+//
+// You might think we could just implement a DHCP client at the protocol
+// level and have cross-platform support for retrieving PAC configuration
+// from DHCP, but unfortunately the DHCP protocol assumes there is a single
+// client per machine (specifically per network interface card), and there
+// is an implicit state machine between the client and server, so adding a
+// second client to the machine would not be advisable (see e.g. some
+// discussion of what can happen at this URL:
+// http://www.net.princeton.edu/multi-dhcp-one-interface-handling.html).
+//
+// Therefore, we have platform-specific implementations, and so we use
+// this factory to select the right one.
+class DhcpProxyScriptFetcherFactory {
+ public:
+  // Ownership is transferred to the caller. url_request_context must be valid
+  // and its lifetime must exceed that of the returned DhcpProxyScriptFetcher.
+  //
+  // Note that while a request is in progress, the fetcher may be holding a
+  // reference to |url_request_context|. Be careful not to create cycles
+  // between the fetcher and the context; you can break such cycles by calling
+  // Cancel().
+  static DhcpProxyScriptFetcher* Create(URLRequestContext* url_request_context);
+
+  // Attempts to enable/disable the DHCP WPAD feature.  Does nothing
+  // if |IsSupported()| returns false.
+  //
+  // The feature is disabled by default, for now.
+  static void SetEnabled(bool enabled);
+
+  // Returns true if the DHCP WPAD feature is enabled.  Always returns
+  // false if |IsSupported()| is false.
+  static bool IsEnabled();
+
+  // Returns true if the DHCP WPAD feature is supported on the current
+  // operating system.
+  static bool IsSupported();
+
+ protected:
+  static bool feature_enabled_;
+
+  DISALLOW_IMPLICIT_CONSTRUCTORS(DhcpProxyScriptFetcherFactory);
+};
+
+}  // namespace net
+
+#endif  // NET_PROXY_DHCP_SCRIPT_FETCHER_FACTORY_H_