gecko-dev/netwerk/base/nsPACMan.h

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

289 строки
8.6 KiB
C
Исходник Обычный вид История

/* -*- Mode: C++; tab-width: 2; indent-tabs-mode: nil; c-basic-offset: 2 -*- */
/* vim:set ts=2 sw=2 sts=2 et cindent: */
2012-05-21 15:12:37 +04:00
/* This Source Code Form is subject to the terms of the Mozilla Public
* License, v. 2.0. If a copy of the MPL was not distributed with this
* file, You can obtain one at http://mozilla.org/MPL/2.0/. */
#ifndef nsPACMan_h__
#define nsPACMan_h__
Bug 356831 - Proxy autodiscovery doesn't check DHCP (option 252) r=bagder,valentin This patch addresses an issue with Firefox's proxy detection on networks which do not have their a proxy auto-configuration (PAC) file hosted at http://wpad/wpad.dat, and instead make use of DHCP option 252 for broadcasting the address of the PAC file. See https://findproxyforurl.com/wpad-introduction/ for an introduction to the protocol. Prior to this patch, proxy auto-detect missed out the DHCP query stage, and just looked for a PAC file at http://wpad/wpad.dat This patch only addresses the issue for Firefox on Windows, although it defines a DHCP client interface which could be implemented on other platforms. The high-level components of this patch are: * nsIDHCPClient.idl - this is an interface which has been defined for querying the DHCP server. * nsPACMan.cpp - where previously when the PAC URL was simply set to a constant of http://wpad/wpad.dat, it now dispatches an asynchronous command to the proxy thread. The class ExecutePACThreadAction has been augmented to include an instruction to 'ConfigureWPAD' (Configure Web-proxy auto-detect), and a new class, 'ConfigureWPADComplete' has been created to relay the result (the URL of the PAC file) back to the nsPACMan object. * nsProtocolProxyService.cpp Minor changes to reflect the fact that the PAC URL not being set does not always mean there is no PAC to be used; instead it could be in the process of being detected. * TestPACMan.cpp This is a new file, and tests only the DHCP auto-detect functionality. Some tests use multiple threads, as they test the non-blocking proxy detection. * DHCPUtils.cpp A class containing the main logic for querying DHCP. * WindowsNetworkFunctionsWrapper.cpp A very thin wrapper around the Windows API calls needed by DHCPUtils. This class was introduced so it could be mocked out in tests. * nsWindowsDHCPClient.cpp * An implementation of the interface defined in nsIDHCPClient.idl. Fairly thin: most logic is implemented in DHCPUtils. * TestDHCPUtils.cpp Tests for DHCPUtils and nsWindowsDHCPClient MozReview-Commit-ID: 4xFQz3tOLEx --HG-- extra : rebase_source : dfd5c588406a8b0d92f91cc8a0038ca722b7140a
2018-06-08 01:07:28 +03:00
#include "mozilla/Atomics.h"
#include "mozilla/Attributes.h"
#include "mozilla/LinkedList.h"
#include "mozilla/Logging.h"
#include "mozilla/net/NeckoTargetHolder.h"
Bug 356831 - Proxy autodiscovery doesn't check DHCP (option 252) r=bagder,valentin This patch addresses an issue with Firefox's proxy detection on networks which do not have their a proxy auto-configuration (PAC) file hosted at http://wpad/wpad.dat, and instead make use of DHCP option 252 for broadcasting the address of the PAC file. See https://findproxyforurl.com/wpad-introduction/ for an introduction to the protocol. Prior to this patch, proxy auto-detect missed out the DHCP query stage, and just looked for a PAC file at http://wpad/wpad.dat This patch only addresses the issue for Firefox on Windows, although it defines a DHCP client interface which could be implemented on other platforms. The high-level components of this patch are: * nsIDHCPClient.idl - this is an interface which has been defined for querying the DHCP server. * nsPACMan.cpp - where previously when the PAC URL was simply set to a constant of http://wpad/wpad.dat, it now dispatches an asynchronous command to the proxy thread. The class ExecutePACThreadAction has been augmented to include an instruction to 'ConfigureWPAD' (Configure Web-proxy auto-detect), and a new class, 'ConfigureWPADComplete' has been created to relay the result (the URL of the PAC file) back to the nsPACMan object. * nsProtocolProxyService.cpp Minor changes to reflect the fact that the PAC URL not being set does not always mean there is no PAC to be used; instead it could be in the process of being detected. * TestPACMan.cpp This is a new file, and tests only the DHCP auto-detect functionality. Some tests use multiple threads, as they test the non-blocking proxy detection. * DHCPUtils.cpp A class containing the main logic for querying DHCP. * WindowsNetworkFunctionsWrapper.cpp A very thin wrapper around the Windows API calls needed by DHCPUtils. This class was introduced so it could be mocked out in tests. * nsWindowsDHCPClient.cpp * An implementation of the interface defined in nsIDHCPClient.idl. Fairly thin: most logic is implemented in DHCPUtils. * TestDHCPUtils.cpp Tests for DHCPUtils and nsWindowsDHCPClient MozReview-Commit-ID: 4xFQz3tOLEx --HG-- extra : rebase_source : dfd5c588406a8b0d92f91cc8a0038ca722b7140a
2018-06-08 01:07:28 +03:00
#include "mozilla/TimeStamp.h"
#include "nsAutoPtr.h"
#include "nsCOMPtr.h"
#include "nsIChannelEventSink.h"
#include "nsIInterfaceRequestor.h"
#include "nsIStreamLoader.h"
#include "nsThreadUtils.h"
#include "nsIURI.h"
#include "nsString.h"
#include "ProxyAutoConfig.h"
class nsISystemProxySettings;
Bug 356831 - Proxy autodiscovery doesn't check DHCP (option 252) r=bagder,valentin This patch addresses an issue with Firefox's proxy detection on networks which do not have their a proxy auto-configuration (PAC) file hosted at http://wpad/wpad.dat, and instead make use of DHCP option 252 for broadcasting the address of the PAC file. See https://findproxyforurl.com/wpad-introduction/ for an introduction to the protocol. Prior to this patch, proxy auto-detect missed out the DHCP query stage, and just looked for a PAC file at http://wpad/wpad.dat This patch only addresses the issue for Firefox on Windows, although it defines a DHCP client interface which could be implemented on other platforms. The high-level components of this patch are: * nsIDHCPClient.idl - this is an interface which has been defined for querying the DHCP server. * nsPACMan.cpp - where previously when the PAC URL was simply set to a constant of http://wpad/wpad.dat, it now dispatches an asynchronous command to the proxy thread. The class ExecutePACThreadAction has been augmented to include an instruction to 'ConfigureWPAD' (Configure Web-proxy auto-detect), and a new class, 'ConfigureWPADComplete' has been created to relay the result (the URL of the PAC file) back to the nsPACMan object. * nsProtocolProxyService.cpp Minor changes to reflect the fact that the PAC URL not being set does not always mean there is no PAC to be used; instead it could be in the process of being detected. * TestPACMan.cpp This is a new file, and tests only the DHCP auto-detect functionality. Some tests use multiple threads, as they test the non-blocking proxy detection. * DHCPUtils.cpp A class containing the main logic for querying DHCP. * WindowsNetworkFunctionsWrapper.cpp A very thin wrapper around the Windows API calls needed by DHCPUtils. This class was introduced so it could be mocked out in tests. * nsWindowsDHCPClient.cpp * An implementation of the interface defined in nsIDHCPClient.idl. Fairly thin: most logic is implemented in DHCPUtils. * TestDHCPUtils.cpp Tests for DHCPUtils and nsWindowsDHCPClient MozReview-Commit-ID: 4xFQz3tOLEx --HG-- extra : rebase_source : dfd5c588406a8b0d92f91cc8a0038ca722b7140a
2018-06-08 01:07:28 +03:00
class nsIDHCPClient;
class nsIThread;
namespace mozilla {
namespace net {
class nsPACMan;
class WaitForThreadShutdown;
/**
* This class defines a callback interface used by AsyncGetProxyForURI.
*/
class NS_NO_VTABLE nsPACManCallback : public nsISupports {
public:
/**
* This method is invoked on the same thread that called AsyncGetProxyForURI.
*
* @param status
* This parameter indicates whether or not the PAC query succeeded.
* @param pacString
* This parameter holds the value of the PAC string. It is empty when
* status is a failure code.
* @param newPACURL
* This parameter holds the URL of a new PAC file that should be loaded
* before the query is evaluated again. At least one of pacString and
* newPACURL should be 0 length.
*/
virtual void OnQueryComplete(nsresult status, const nsACString& pacString,
const nsACString& newPACURL) = 0;
};
class PendingPACQuery final : public Runnable,
public LinkedListElement<PendingPACQuery> {
public:
PendingPACQuery(nsPACMan* pacMan, nsIURI* uri, nsPACManCallback* callback,
bool mainThreadResponse);
// can be called from either thread
void Complete(nsresult status, const nsACString& pacString);
void UseAlternatePACFile(const nsACString& pacURL);
nsCString mSpec;
nsCString mScheme;
nsCString mHost;
int32_t mPort;
NS_IMETHOD Run(void) override; /* Runnable */
private:
nsPACMan* mPACMan; // weak reference
private:
Bug 1207245 - part 6 - rename nsRefPtr<T> to RefPtr<T>; r=ehsan; a=Tomcat The bulk of this commit was generated with a script, executed at the top level of a typical source code checkout. The only non-machine-generated part was modifying MFBT's moz.build to reflect the new naming. CLOSED TREE makes big refactorings like this a piece of cake. # The main substitution. find . -name '*.cpp' -o -name '*.cc' -o -name '*.h' -o -name '*.mm' -o -name '*.idl'| \ xargs perl -p -i -e ' s/nsRefPtr\.h/RefPtr\.h/g; # handle includes s/nsRefPtr ?</RefPtr</g; # handle declarations and variables ' # Handle a special friend declaration in gfx/layers/AtomicRefCountedWithFinalize.h. perl -p -i -e 's/::nsRefPtr;/::RefPtr;/' gfx/layers/AtomicRefCountedWithFinalize.h # Handle nsRefPtr.h itself, a couple places that define constructors # from nsRefPtr, and code generators specially. We do this here, rather # than indiscriminantly s/nsRefPtr/RefPtr/, because that would rename # things like nsRefPtrHashtable. perl -p -i -e 's/nsRefPtr/RefPtr/g' \ mfbt/nsRefPtr.h \ xpcom/glue/nsCOMPtr.h \ xpcom/base/OwningNonNull.h \ ipc/ipdl/ipdl/lower.py \ ipc/ipdl/ipdl/builtin.py \ dom/bindings/Codegen.py \ python/lldbutils/lldbutils/utils.py # In our indiscriminate substitution above, we renamed # nsRefPtrGetterAddRefs, the class behind getter_AddRefs. Fix that up. find . -name '*.cpp' -o -name '*.h' -o -name '*.idl' | \ xargs perl -p -i -e 's/nsRefPtrGetterAddRefs/RefPtrGetterAddRefs/g' if [ -d .git ]; then git mv mfbt/nsRefPtr.h mfbt/RefPtr.h else hg mv mfbt/nsRefPtr.h mfbt/RefPtr.h fi --HG-- rename : mfbt/nsRefPtr.h => mfbt/RefPtr.h
2015-10-18 08:24:48 +03:00
RefPtr<nsPACManCallback> mCallback;
bool mOnMainThreadOnly;
};
/**
* This class provides an abstraction layer above the PAC thread. The methods
* defined on this class are intended to be called on the main thread only.
*/
class nsPACMan final : public nsIStreamLoaderObserver,
public nsIInterfaceRequestor,
public nsIChannelEventSink,
public NeckoTargetHolder {
public:
NS_DECL_THREADSAFE_ISUPPORTS
explicit nsPACMan(nsIEventTarget* mainThreadEventTarget);
/**
* This method may be called to shutdown the PAC manager. Any async queries
* that have not yet completed will either finish normally or be canceled by
* the time this method returns.
*/
void Shutdown();
/**
* This method queries a PAC result asynchronously. The callback runs on the
* calling thread. If the PAC file has not yet been loaded, then this method
* will queue up the request, and complete it once the PAC file has been
* loaded.
*
* @param uri
* The URI to query.
* @param callback
* The callback to run once the PAC result is available.
* @param mustCallbackOnMainThread
* If set to false the callback can be made from the PAC thread
*/
nsresult AsyncGetProxyForURI(nsIURI* uri, nsPACManCallback* callback,
bool mustCallbackOnMainThread);
/**
* This method may be called to reload the PAC file. While we are loading
* the PAC file, any asynchronous PAC queries will be queued up to be
* processed once the PAC file finishes loading.
*
Bug 356831 - Proxy autodiscovery doesn't check DHCP (option 252) r=bagder,valentin This patch addresses an issue with Firefox's proxy detection on networks which do not have their a proxy auto-configuration (PAC) file hosted at http://wpad/wpad.dat, and instead make use of DHCP option 252 for broadcasting the address of the PAC file. See https://findproxyforurl.com/wpad-introduction/ for an introduction to the protocol. Prior to this patch, proxy auto-detect missed out the DHCP query stage, and just looked for a PAC file at http://wpad/wpad.dat This patch only addresses the issue for Firefox on Windows, although it defines a DHCP client interface which could be implemented on other platforms. The high-level components of this patch are: * nsIDHCPClient.idl - this is an interface which has been defined for querying the DHCP server. * nsPACMan.cpp - where previously when the PAC URL was simply set to a constant of http://wpad/wpad.dat, it now dispatches an asynchronous command to the proxy thread. The class ExecutePACThreadAction has been augmented to include an instruction to 'ConfigureWPAD' (Configure Web-proxy auto-detect), and a new class, 'ConfigureWPADComplete' has been created to relay the result (the URL of the PAC file) back to the nsPACMan object. * nsProtocolProxyService.cpp Minor changes to reflect the fact that the PAC URL not being set does not always mean there is no PAC to be used; instead it could be in the process of being detected. * TestPACMan.cpp This is a new file, and tests only the DHCP auto-detect functionality. Some tests use multiple threads, as they test the non-blocking proxy detection. * DHCPUtils.cpp A class containing the main logic for querying DHCP. * WindowsNetworkFunctionsWrapper.cpp A very thin wrapper around the Windows API calls needed by DHCPUtils. This class was introduced so it could be mocked out in tests. * nsWindowsDHCPClient.cpp * An implementation of the interface defined in nsIDHCPClient.idl. Fairly thin: most logic is implemented in DHCPUtils. * TestDHCPUtils.cpp Tests for DHCPUtils and nsWindowsDHCPClient MozReview-Commit-ID: 4xFQz3tOLEx --HG-- extra : rebase_source : dfd5c588406a8b0d92f91cc8a0038ca722b7140a
2018-06-08 01:07:28 +03:00
* @param aSpec
* The non normalized uri spec of this URI used for comparison with
* system proxy settings to determine if the PAC uri has changed.
*/
nsresult LoadPACFromURI(const nsACString& aSpec);
/**
* Returns true if we are currently loading the PAC file.
*/
bool IsLoading() { return mLoader != nullptr; }
/**
* Returns true if the given URI matches the URI of our PAC file or the
* URI it has been redirected to. In the case of a chain of redirections
* only the current one being followed and the original are considered
* becuase this information is used, respectively, to determine if we
* should bypass the proxy (to fetch the pac file) or if the pac
* configuration has changed (and we should reload the pac file)
*/
bool IsPACURI(const nsACString& spec) {
return mPACURISpec.Equals(spec) || mPACURIRedirectSpec.Equals(spec) ||
mNormalPACURISpec.Equals(spec);
}
bool IsPACURI(nsIURI* uri) {
if (mPACURISpec.IsEmpty() && mPACURIRedirectSpec.IsEmpty()) {
return false;
}
nsAutoCString tmp;
nsresult rv = uri->GetSpec(tmp);
if (NS_FAILED(rv)) {
return false;
}
return IsPACURI(tmp);
}
Bug 356831 - Proxy autodiscovery doesn't check DHCP (option 252) r=bagder,valentin This patch addresses an issue with Firefox's proxy detection on networks which do not have their a proxy auto-configuration (PAC) file hosted at http://wpad/wpad.dat, and instead make use of DHCP option 252 for broadcasting the address of the PAC file. See https://findproxyforurl.com/wpad-introduction/ for an introduction to the protocol. Prior to this patch, proxy auto-detect missed out the DHCP query stage, and just looked for a PAC file at http://wpad/wpad.dat This patch only addresses the issue for Firefox on Windows, although it defines a DHCP client interface which could be implemented on other platforms. The high-level components of this patch are: * nsIDHCPClient.idl - this is an interface which has been defined for querying the DHCP server. * nsPACMan.cpp - where previously when the PAC URL was simply set to a constant of http://wpad/wpad.dat, it now dispatches an asynchronous command to the proxy thread. The class ExecutePACThreadAction has been augmented to include an instruction to 'ConfigureWPAD' (Configure Web-proxy auto-detect), and a new class, 'ConfigureWPADComplete' has been created to relay the result (the URL of the PAC file) back to the nsPACMan object. * nsProtocolProxyService.cpp Minor changes to reflect the fact that the PAC URL not being set does not always mean there is no PAC to be used; instead it could be in the process of being detected. * TestPACMan.cpp This is a new file, and tests only the DHCP auto-detect functionality. Some tests use multiple threads, as they test the non-blocking proxy detection. * DHCPUtils.cpp A class containing the main logic for querying DHCP. * WindowsNetworkFunctionsWrapper.cpp A very thin wrapper around the Windows API calls needed by DHCPUtils. This class was introduced so it could be mocked out in tests. * nsWindowsDHCPClient.cpp * An implementation of the interface defined in nsIDHCPClient.idl. Fairly thin: most logic is implemented in DHCPUtils. * TestDHCPUtils.cpp Tests for DHCPUtils and nsWindowsDHCPClient MozReview-Commit-ID: 4xFQz3tOLEx --HG-- extra : rebase_source : dfd5c588406a8b0d92f91cc8a0038ca722b7140a
2018-06-08 01:07:28 +03:00
bool IsUsingWPAD() { return mAutoDetect; }
nsresult Init(nsISystemProxySettings*);
static nsPACMan* sInstance;
// PAC thread operations only
void ProcessPendingQ();
void CancelPendingQ(nsresult, bool aShutdown);
Bug 356831 - Proxy autodiscovery doesn't check DHCP (option 252) r=bagder,valentin This patch addresses an issue with Firefox's proxy detection on networks which do not have their a proxy auto-configuration (PAC) file hosted at http://wpad/wpad.dat, and instead make use of DHCP option 252 for broadcasting the address of the PAC file. See https://findproxyforurl.com/wpad-introduction/ for an introduction to the protocol. Prior to this patch, proxy auto-detect missed out the DHCP query stage, and just looked for a PAC file at http://wpad/wpad.dat This patch only addresses the issue for Firefox on Windows, although it defines a DHCP client interface which could be implemented on other platforms. The high-level components of this patch are: * nsIDHCPClient.idl - this is an interface which has been defined for querying the DHCP server. * nsPACMan.cpp - where previously when the PAC URL was simply set to a constant of http://wpad/wpad.dat, it now dispatches an asynchronous command to the proxy thread. The class ExecutePACThreadAction has been augmented to include an instruction to 'ConfigureWPAD' (Configure Web-proxy auto-detect), and a new class, 'ConfigureWPADComplete' has been created to relay the result (the URL of the PAC file) back to the nsPACMan object. * nsProtocolProxyService.cpp Minor changes to reflect the fact that the PAC URL not being set does not always mean there is no PAC to be used; instead it could be in the process of being detected. * TestPACMan.cpp This is a new file, and tests only the DHCP auto-detect functionality. Some tests use multiple threads, as they test the non-blocking proxy detection. * DHCPUtils.cpp A class containing the main logic for querying DHCP. * WindowsNetworkFunctionsWrapper.cpp A very thin wrapper around the Windows API calls needed by DHCPUtils. This class was introduced so it could be mocked out in tests. * nsWindowsDHCPClient.cpp * An implementation of the interface defined in nsIDHCPClient.idl. Fairly thin: most logic is implemented in DHCPUtils. * TestDHCPUtils.cpp Tests for DHCPUtils and nsWindowsDHCPClient MozReview-Commit-ID: 4xFQz3tOLEx --HG-- extra : rebase_source : dfd5c588406a8b0d92f91cc8a0038ca722b7140a
2018-06-08 01:07:28 +03:00
void SetWPADOverDHCPEnabled(bool aValue) { mWPADOverDHCPEnabled = aValue; }
private:
NS_DECL_NSISTREAMLOADEROBSERVER
NS_DECL_NSIINTERFACEREQUESTOR
NS_DECL_NSICHANNELEVENTSINK
friend class PendingPACQuery;
friend class PACLoadComplete;
Bug 356831 - Proxy autodiscovery doesn't check DHCP (option 252) r=bagder,valentin This patch addresses an issue with Firefox's proxy detection on networks which do not have their a proxy auto-configuration (PAC) file hosted at http://wpad/wpad.dat, and instead make use of DHCP option 252 for broadcasting the address of the PAC file. See https://findproxyforurl.com/wpad-introduction/ for an introduction to the protocol. Prior to this patch, proxy auto-detect missed out the DHCP query stage, and just looked for a PAC file at http://wpad/wpad.dat This patch only addresses the issue for Firefox on Windows, although it defines a DHCP client interface which could be implemented on other platforms. The high-level components of this patch are: * nsIDHCPClient.idl - this is an interface which has been defined for querying the DHCP server. * nsPACMan.cpp - where previously when the PAC URL was simply set to a constant of http://wpad/wpad.dat, it now dispatches an asynchronous command to the proxy thread. The class ExecutePACThreadAction has been augmented to include an instruction to 'ConfigureWPAD' (Configure Web-proxy auto-detect), and a new class, 'ConfigureWPADComplete' has been created to relay the result (the URL of the PAC file) back to the nsPACMan object. * nsProtocolProxyService.cpp Minor changes to reflect the fact that the PAC URL not being set does not always mean there is no PAC to be used; instead it could be in the process of being detected. * TestPACMan.cpp This is a new file, and tests only the DHCP auto-detect functionality. Some tests use multiple threads, as they test the non-blocking proxy detection. * DHCPUtils.cpp A class containing the main logic for querying DHCP. * WindowsNetworkFunctionsWrapper.cpp A very thin wrapper around the Windows API calls needed by DHCPUtils. This class was introduced so it could be mocked out in tests. * nsWindowsDHCPClient.cpp * An implementation of the interface defined in nsIDHCPClient.idl. Fairly thin: most logic is implemented in DHCPUtils. * TestDHCPUtils.cpp Tests for DHCPUtils and nsWindowsDHCPClient MozReview-Commit-ID: 4xFQz3tOLEx --HG-- extra : rebase_source : dfd5c588406a8b0d92f91cc8a0038ca722b7140a
2018-06-08 01:07:28 +03:00
friend class ConfigureWPADComplete;
friend class ExecutePACThreadAction;
friend class WaitForThreadShutdown;
Bug 356831 - Proxy autodiscovery doesn't check DHCP (option 252) r=bagder,valentin This patch addresses an issue with Firefox's proxy detection on networks which do not have their a proxy auto-configuration (PAC) file hosted at http://wpad/wpad.dat, and instead make use of DHCP option 252 for broadcasting the address of the PAC file. See https://findproxyforurl.com/wpad-introduction/ for an introduction to the protocol. Prior to this patch, proxy auto-detect missed out the DHCP query stage, and just looked for a PAC file at http://wpad/wpad.dat This patch only addresses the issue for Firefox on Windows, although it defines a DHCP client interface which could be implemented on other platforms. The high-level components of this patch are: * nsIDHCPClient.idl - this is an interface which has been defined for querying the DHCP server. * nsPACMan.cpp - where previously when the PAC URL was simply set to a constant of http://wpad/wpad.dat, it now dispatches an asynchronous command to the proxy thread. The class ExecutePACThreadAction has been augmented to include an instruction to 'ConfigureWPAD' (Configure Web-proxy auto-detect), and a new class, 'ConfigureWPADComplete' has been created to relay the result (the URL of the PAC file) back to the nsPACMan object. * nsProtocolProxyService.cpp Minor changes to reflect the fact that the PAC URL not being set does not always mean there is no PAC to be used; instead it could be in the process of being detected. * TestPACMan.cpp This is a new file, and tests only the DHCP auto-detect functionality. Some tests use multiple threads, as they test the non-blocking proxy detection. * DHCPUtils.cpp A class containing the main logic for querying DHCP. * WindowsNetworkFunctionsWrapper.cpp A very thin wrapper around the Windows API calls needed by DHCPUtils. This class was introduced so it could be mocked out in tests. * nsWindowsDHCPClient.cpp * An implementation of the interface defined in nsIDHCPClient.idl. Fairly thin: most logic is implemented in DHCPUtils. * TestDHCPUtils.cpp Tests for DHCPUtils and nsWindowsDHCPClient MozReview-Commit-ID: 4xFQz3tOLEx --HG-- extra : rebase_source : dfd5c588406a8b0d92f91cc8a0038ca722b7140a
2018-06-08 01:07:28 +03:00
friend class TestPACMan;
~nsPACMan();
/**
* Cancel any existing load if any.
*/
void CancelExistingLoad();
/**
* Start loading the PAC file.
*/
void StartLoading();
Bug 356831 - Proxy autodiscovery doesn't check DHCP (option 252) r=bagder,valentin This patch addresses an issue with Firefox's proxy detection on networks which do not have their a proxy auto-configuration (PAC) file hosted at http://wpad/wpad.dat, and instead make use of DHCP option 252 for broadcasting the address of the PAC file. See https://findproxyforurl.com/wpad-introduction/ for an introduction to the protocol. Prior to this patch, proxy auto-detect missed out the DHCP query stage, and just looked for a PAC file at http://wpad/wpad.dat This patch only addresses the issue for Firefox on Windows, although it defines a DHCP client interface which could be implemented on other platforms. The high-level components of this patch are: * nsIDHCPClient.idl - this is an interface which has been defined for querying the DHCP server. * nsPACMan.cpp - where previously when the PAC URL was simply set to a constant of http://wpad/wpad.dat, it now dispatches an asynchronous command to the proxy thread. The class ExecutePACThreadAction has been augmented to include an instruction to 'ConfigureWPAD' (Configure Web-proxy auto-detect), and a new class, 'ConfigureWPADComplete' has been created to relay the result (the URL of the PAC file) back to the nsPACMan object. * nsProtocolProxyService.cpp Minor changes to reflect the fact that the PAC URL not being set does not always mean there is no PAC to be used; instead it could be in the process of being detected. * TestPACMan.cpp This is a new file, and tests only the DHCP auto-detect functionality. Some tests use multiple threads, as they test the non-blocking proxy detection. * DHCPUtils.cpp A class containing the main logic for querying DHCP. * WindowsNetworkFunctionsWrapper.cpp A very thin wrapper around the Windows API calls needed by DHCPUtils. This class was introduced so it could be mocked out in tests. * nsWindowsDHCPClient.cpp * An implementation of the interface defined in nsIDHCPClient.idl. Fairly thin: most logic is implemented in DHCPUtils. * TestDHCPUtils.cpp Tests for DHCPUtils and nsWindowsDHCPClient MozReview-Commit-ID: 4xFQz3tOLEx --HG-- extra : rebase_source : dfd5c588406a8b0d92f91cc8a0038ca722b7140a
2018-06-08 01:07:28 +03:00
/**
* Continue loading the PAC file.
*/
void ContinueLoadingAfterPACUriKnown();
/**
* This method may be called to reload the PAC file. While we are loading
* the PAC file, any asynchronous PAC queries will be queued up to be
* processed once the PAC file finishes loading.
*
* @param aSpec
* The non normalized uri spec of this URI used for comparison with
* system proxy settings to determine if the PAC uri has changed.
* @param aResetLoadFailureCount
* A flag saying whether the exponential back-off for attempting to
* reload the PAC should be reset.
*/
nsresult LoadPACFromURI(const nsACString& aSpec, bool aResetLoadFailureCount);
/**
* Reload the PAC file if there is reason to.
*/
void MaybeReloadPAC();
/**
* Called when we fail to load the PAC file.
*/
void OnLoadFailure();
/**
* PostQuery() only runs on the PAC thread and it is used to
* place a pendingPACQuery into the queue and potentially
* execute the queue if it was otherwise empty
*/
nsresult PostQuery(PendingPACQuery* query);
Bug 356831 - Proxy autodiscovery doesn't check DHCP (option 252) r=bagder,valentin This patch addresses an issue with Firefox's proxy detection on networks which do not have their a proxy auto-configuration (PAC) file hosted at http://wpad/wpad.dat, and instead make use of DHCP option 252 for broadcasting the address of the PAC file. See https://findproxyforurl.com/wpad-introduction/ for an introduction to the protocol. Prior to this patch, proxy auto-detect missed out the DHCP query stage, and just looked for a PAC file at http://wpad/wpad.dat This patch only addresses the issue for Firefox on Windows, although it defines a DHCP client interface which could be implemented on other platforms. The high-level components of this patch are: * nsIDHCPClient.idl - this is an interface which has been defined for querying the DHCP server. * nsPACMan.cpp - where previously when the PAC URL was simply set to a constant of http://wpad/wpad.dat, it now dispatches an asynchronous command to the proxy thread. The class ExecutePACThreadAction has been augmented to include an instruction to 'ConfigureWPAD' (Configure Web-proxy auto-detect), and a new class, 'ConfigureWPADComplete' has been created to relay the result (the URL of the PAC file) back to the nsPACMan object. * nsProtocolProxyService.cpp Minor changes to reflect the fact that the PAC URL not being set does not always mean there is no PAC to be used; instead it could be in the process of being detected. * TestPACMan.cpp This is a new file, and tests only the DHCP auto-detect functionality. Some tests use multiple threads, as they test the non-blocking proxy detection. * DHCPUtils.cpp A class containing the main logic for querying DHCP. * WindowsNetworkFunctionsWrapper.cpp A very thin wrapper around the Windows API calls needed by DHCPUtils. This class was introduced so it could be mocked out in tests. * nsWindowsDHCPClient.cpp * An implementation of the interface defined in nsIDHCPClient.idl. Fairly thin: most logic is implemented in DHCPUtils. * TestDHCPUtils.cpp Tests for DHCPUtils and nsWindowsDHCPClient MozReview-Commit-ID: 4xFQz3tOLEx --HG-- extra : rebase_source : dfd5c588406a8b0d92f91cc8a0038ca722b7140a
2018-06-08 01:07:28 +03:00
// Having found the PAC URI on the PAC thread, copy it to a string which
// can be altered on the main thread.
void AssignPACURISpec(const nsACString& aSpec);
Bug 356831 - Proxy autodiscovery doesn't check DHCP (option 252) r=bagder,valentin This patch addresses an issue with Firefox's proxy detection on networks which do not have their a proxy auto-configuration (PAC) file hosted at http://wpad/wpad.dat, and instead make use of DHCP option 252 for broadcasting the address of the PAC file. See https://findproxyforurl.com/wpad-introduction/ for an introduction to the protocol. Prior to this patch, proxy auto-detect missed out the DHCP query stage, and just looked for a PAC file at http://wpad/wpad.dat This patch only addresses the issue for Firefox on Windows, although it defines a DHCP client interface which could be implemented on other platforms. The high-level components of this patch are: * nsIDHCPClient.idl - this is an interface which has been defined for querying the DHCP server. * nsPACMan.cpp - where previously when the PAC URL was simply set to a constant of http://wpad/wpad.dat, it now dispatches an asynchronous command to the proxy thread. The class ExecutePACThreadAction has been augmented to include an instruction to 'ConfigureWPAD' (Configure Web-proxy auto-detect), and a new class, 'ConfigureWPADComplete' has been created to relay the result (the URL of the PAC file) back to the nsPACMan object. * nsProtocolProxyService.cpp Minor changes to reflect the fact that the PAC URL not being set does not always mean there is no PAC to be used; instead it could be in the process of being detected. * TestPACMan.cpp This is a new file, and tests only the DHCP auto-detect functionality. Some tests use multiple threads, as they test the non-blocking proxy detection. * DHCPUtils.cpp A class containing the main logic for querying DHCP. * WindowsNetworkFunctionsWrapper.cpp A very thin wrapper around the Windows API calls needed by DHCPUtils. This class was introduced so it could be mocked out in tests. * nsWindowsDHCPClient.cpp * An implementation of the interface defined in nsIDHCPClient.idl. Fairly thin: most logic is implemented in DHCPUtils. * TestDHCPUtils.cpp Tests for DHCPUtils and nsWindowsDHCPClient MozReview-Commit-ID: 4xFQz3tOLEx --HG-- extra : rebase_source : dfd5c588406a8b0d92f91cc8a0038ca722b7140a
2018-06-08 01:07:28 +03:00
// PAC thread operations only
void PostProcessPendingQ();
void PostCancelPendingQ(nsresult, bool aShutdown = false);
bool ProcessPending();
nsresult GetPACFromDHCP(nsACString& aSpec);
nsresult ConfigureWPAD(nsACString& aSpec);
private:
/**
* Dispatches a runnable to the PAC processing thread. Handles lazy
* instantiation of the thread.
*
* @param aEvent The event to disptach.
* @param aSync Whether or not this should be synchronous dispatch.
*/
nsresult DispatchToPAC(already_AddRefed<nsIRunnable> aEvent,
bool aSync = false);
ProxyAutoConfig mPAC;
nsCOMPtr<nsIThread> mPACThread;
nsCOMPtr<nsISystemProxySettings> mSystemProxySettings;
Bug 356831 - Proxy autodiscovery doesn't check DHCP (option 252) r=bagder,valentin This patch addresses an issue with Firefox's proxy detection on networks which do not have their a proxy auto-configuration (PAC) file hosted at http://wpad/wpad.dat, and instead make use of DHCP option 252 for broadcasting the address of the PAC file. See https://findproxyforurl.com/wpad-introduction/ for an introduction to the protocol. Prior to this patch, proxy auto-detect missed out the DHCP query stage, and just looked for a PAC file at http://wpad/wpad.dat This patch only addresses the issue for Firefox on Windows, although it defines a DHCP client interface which could be implemented on other platforms. The high-level components of this patch are: * nsIDHCPClient.idl - this is an interface which has been defined for querying the DHCP server. * nsPACMan.cpp - where previously when the PAC URL was simply set to a constant of http://wpad/wpad.dat, it now dispatches an asynchronous command to the proxy thread. The class ExecutePACThreadAction has been augmented to include an instruction to 'ConfigureWPAD' (Configure Web-proxy auto-detect), and a new class, 'ConfigureWPADComplete' has been created to relay the result (the URL of the PAC file) back to the nsPACMan object. * nsProtocolProxyService.cpp Minor changes to reflect the fact that the PAC URL not being set does not always mean there is no PAC to be used; instead it could be in the process of being detected. * TestPACMan.cpp This is a new file, and tests only the DHCP auto-detect functionality. Some tests use multiple threads, as they test the non-blocking proxy detection. * DHCPUtils.cpp A class containing the main logic for querying DHCP. * WindowsNetworkFunctionsWrapper.cpp A very thin wrapper around the Windows API calls needed by DHCPUtils. This class was introduced so it could be mocked out in tests. * nsWindowsDHCPClient.cpp * An implementation of the interface defined in nsIDHCPClient.idl. Fairly thin: most logic is implemented in DHCPUtils. * TestDHCPUtils.cpp Tests for DHCPUtils and nsWindowsDHCPClient MozReview-Commit-ID: 4xFQz3tOLEx --HG-- extra : rebase_source : dfd5c588406a8b0d92f91cc8a0038ca722b7140a
2018-06-08 01:07:28 +03:00
nsCOMPtr<nsIDHCPClient> mDHCPClient;
LinkedList<PendingPACQuery> mPendingQ; /* pac thread only */
// These specs are not nsIURI so that they can be used off the main thread.
// The non-normalized versions are directly from the configuration, the
// normalized version has been extracted from an nsIURI
nsCString mPACURISpec;
nsCString mPACURIRedirectSpec;
nsCString mNormalPACURISpec;
nsCOMPtr<nsIStreamLoader> mLoader;
bool mLoadPending;
Atomic<bool, Relaxed> mShutdown;
TimeStamp mScheduledReload;
uint32_t mLoadFailureCount;
bool mInProgress;
bool mIncludePath;
Bug 356831 - Proxy autodiscovery doesn't check DHCP (option 252) r=bagder,valentin This patch addresses an issue with Firefox's proxy detection on networks which do not have their a proxy auto-configuration (PAC) file hosted at http://wpad/wpad.dat, and instead make use of DHCP option 252 for broadcasting the address of the PAC file. See https://findproxyforurl.com/wpad-introduction/ for an introduction to the protocol. Prior to this patch, proxy auto-detect missed out the DHCP query stage, and just looked for a PAC file at http://wpad/wpad.dat This patch only addresses the issue for Firefox on Windows, although it defines a DHCP client interface which could be implemented on other platforms. The high-level components of this patch are: * nsIDHCPClient.idl - this is an interface which has been defined for querying the DHCP server. * nsPACMan.cpp - where previously when the PAC URL was simply set to a constant of http://wpad/wpad.dat, it now dispatches an asynchronous command to the proxy thread. The class ExecutePACThreadAction has been augmented to include an instruction to 'ConfigureWPAD' (Configure Web-proxy auto-detect), and a new class, 'ConfigureWPADComplete' has been created to relay the result (the URL of the PAC file) back to the nsPACMan object. * nsProtocolProxyService.cpp Minor changes to reflect the fact that the PAC URL not being set does not always mean there is no PAC to be used; instead it could be in the process of being detected. * TestPACMan.cpp This is a new file, and tests only the DHCP auto-detect functionality. Some tests use multiple threads, as they test the non-blocking proxy detection. * DHCPUtils.cpp A class containing the main logic for querying DHCP. * WindowsNetworkFunctionsWrapper.cpp A very thin wrapper around the Windows API calls needed by DHCPUtils. This class was introduced so it could be mocked out in tests. * nsWindowsDHCPClient.cpp * An implementation of the interface defined in nsIDHCPClient.idl. Fairly thin: most logic is implemented in DHCPUtils. * TestDHCPUtils.cpp Tests for DHCPUtils and nsWindowsDHCPClient MozReview-Commit-ID: 4xFQz3tOLEx --HG-- extra : rebase_source : dfd5c588406a8b0d92f91cc8a0038ca722b7140a
2018-06-08 01:07:28 +03:00
bool mAutoDetect;
bool mWPADOverDHCPEnabled;
int32_t mProxyConfigType;
};
extern LazyLogModule gProxyLog;
} // namespace net
} // namespace mozilla
#endif // nsPACMan_h__