.Net Framework proxy detecting/loading from a middle tier/service environment
I got pinged by several customers on .Net Framework proxy detection and how the proxy server been loaded or used in a .Net applicaton domain. The typical scenario is: cusotmer saw some inconsistent behavior for using Proxy or not using Proxy in a middle tier/service environement, such as a windows service using WCF calling another backend webservice, or ASP.NET calling another backend WCF service.
Here is my answer: the .Net Framework proxy detecting/loading, is using the following MSDN setting combination:
https://msdn.microsoft.com/en-us/library/sa91de1e.aspx
<proxy
autoDetect="true|false|unspecified"
bypassonlocal="true|false|unspecified"
proxyaddress="uriString"
scriptLocation="uriString"
usesystemdefault="true|false|unspecified "
/>
autoDetect |
Specifies whether the proxy is automatically detected. The default value is unspecified. |
bypassonlocal |
Specifies whether the proxy is bypassed for local resources. Local resources include the local server (https://localhost, https://loopback, or https://127.0.0.1) and a URI without a period (https://webserver). The default value is unspecified. |
proxyaddress |
Specifies the proxy URI to use. |
scriptLocation |
Specifies the location of the configuration script. |
usesystemdefault |
Specifies whether to use Internet Explorer proxy settings. If set to true, subsequent attributes will override Internet Explorer proxy settings. The default value is unspecified. |
By default, autoDetect is set as unspecified, which equals to enabled. It means the proxy is automatically detected. The proxy auto detection follows this white paper for design.
https://msdn.microsoft.com/en-us/magazine/cc300743.aspx
“Automatic configuration is a two-step process. First, the user agent (Internet Explorer or the .NET Framework) tries to discover the URL of a configuration script. Typically, the configuration script is a JavaScript file that contains logic to determine whether to use a proxy and what proxy to use for a given target resource. The protocol for automatic detection is documented at Web Proxy Auto-Discovery Protocol. The user agent first tries a DHCPINFORM message. The reply to this message contains the URL of the configuration script. If that doesn't work, a DNS lookup for a well-known alias, WPAD, is issued. Then the configuration script's location is determined as https://<machine>/wpad.dat where the machine name is the result of the DNS lookup.
The second step is to download the configuration script from the URL and run the script. The specification of what the configuration script looks like is at Navigator Proxy Auto-Config File Format. And then parse and run the proxy auto configuration (PAC) script.”
This detection implementation is expensive, take time and also require you have either DHCP server or DNS set up correctly. If you are using a middle tier server type of client, for performance consideration, we will need to disable it to save the time spent on proxy detection routine.
The 2nd proxy detection is using IE proxy. It is controlled through setting, usesystemdefault="true|false|unspecified "
usesystemdefault: Specifies whether to use Internet Explorer proxy settings. If it is set to true, subsequent attributes will override Internet Explorer proxy settings. The default value is unspecified, which equals to true.
But this setting may not work well for a service. A service typically doesn’t have any IE profile with proxy setting. Creating a IE profile for a service account is like a hacking. usesystemdefault setting is more designed for a log on user type of application instead of service. IE proxy connection is implemented through wininet.dll, but wininet.dll is not supported in service.
https://support.microsoft.com/kb/238425
INFO: WinInet Not Supported for Use in Services
So, we will discourage using the IE proxy setting and creating an IE profile for a service account to load proxy in .Net as it will make the proxy loading behavior hard to be predicted if a service has some user impersonation implemented.
For the middle tier or service type of client app, we can set the proxy use the following choice:
bypassonlocal="true|false|unspecified"
proxyaddress="uriString"
scriptLocation="uriString"
We can using proxy address to well specify the proxy information combined with proxy bypass rule. If you have to use the proxy auto configuration (PAC) script rule, you can use the choice in scriptLocation. This way, we can well control the proxy loading behavior to avoid delay on Proxy detection or unpredictable result for using impersonated account to load IE proxy setting.
A configuration sample is listed below:
<configuration>
<system.net>
<defaultProxy>
<proxy
autoDetect="false"
usesystemdefault="false"
proxyaddress="https://myproxy:80"
bypassonlocal="true"
/>
<bypasslist>
<add address="[a-z]+\.contoso\.com$" />
<add address="127.0.0.1" />
</bypasslist>
</defaultProxy>
</system.net>
</configuration>