Configuration Http Proxies in WCF

When using Http, proxy configuration madness is a fact of life. If misconfigured, you can wind up trying to decipher obtuse 502 (Bad Gateway) and 504 (Gateway Timeout) errors.

Fortunately there are a number of binding settings available in WCF to control your Http proxy usage. These settings are available directly on BasicHttpBinding and WsHttpBinding (as well as on HttpTransportBindingElement when you are using a CustomBinding).

  • public bool UseDefaultWebProxy (default == true): if set to true, will use the global value HttpWebRequest.DefaultProxy as your proxy. HttpWebRequest.DefaultProxy is controllable through System.Net config, and defaults to using the system proxy settings (i.e. when you see in your Internet Explorer properties).
  • public Uri ProxyAddress (default == null): If you want to specify a proxy directly you can set a proxy Uri directly here. To ensure no proxy is used you can specify “null” here. In both cases be sure to set UseDefaultWebProxy = false as well.
  • public bool BypassProxyOnLocal (default == false): used in conjunction with ProxyAddress for when you specify a proxy. If you want “local” addresses (i.e. addresses on your intranet) to connect directly without using the proxy, set this value to true.
  • public HttpProxyCredentialType HttpTransportSecurity.ProxyCredentialType (default == None): Specifies the authentication mode used with your Http proxy. For custom bindings the equivalent setting is public AuthenticationSchemes ProxyAuthenticationScheme (default == Anonymous) on HttpTransportBindingElement. For proxy authentication we will obtain the credential using the shared WCF provisioning framework (SecurityTokenProvider, etc). We simply pass in the proxy address (rather than the target address) for acquiring these credentials.

One last note about proxies: if you see a 502 or a 504 error returned to your client, then your client is using a proxy server. If this was not your intention, you can disable the server by setting UseDefaultWebProxy to false, and using the default ProxyAddress of null. The other possibility is that your proxy is misconfigured and you can use the above settings to rectify that situation 🙂

10 thoughts on “Configuration Http Proxies in WCF

  1. Emil

    I am having the same issue. It ignores proxy settings and connects without the proxy.

    Here is my client configuration:

    Reply
  2. Kenny

    I’d need to see you configuration (it seems to have gotten stripped in the comment) to know for sure. If you have the default settings then you will use what’s in IE. Otherwise you need to remember to set defaultWebProxy=false as well as setting proxyAddress=”http://myProxy” from within your config on the basicHttpBinding or wsHttpBinding.

    Reply
  3. Pingback: kennyw.com » Blog Archive » Setting Credentials for your HTTP Proxy

  4. Jason

    I’m new to WCF and am trying to get a handle on LINQ via the walkthrough in MSDN which connects to http://terraserver.microsoft.com/TerraService2.asmx. However I am behind a corporate ISA firewall/proxy that requires authentication. I can surf the web with IE just fine so my default proxy settings are OK. but the following app.config settings still fail with: (407) Proxy Authentication Required ( The ISA Server requires authorization to fulfill the request. Access to the Web Proxy filter is denied). The settings are the auto-generated ones with proxyCredentialType=”Windows”. I also added the impersonate bit just in case – not sure if it’s relevant though.

    I assume I am not setting the proxy credentials correctly and would appreciate any pointers on how to do this…

    Reply
  5. Kenny

    If your IE settings are correct for hitting the terra server, then you shouldn’t need any specific WCF proxy settings. The default of “UseDefaultWebProxy = true” will simply use the settings from IE by default

    Reply
  6. Pingback: WCF Proxy Server settings not working | keyongtech

  7. Wout

    So if I understand correctly, there is no way to specify username/password just for the http proxy like it worked in .NET 2.0 (things did work and also understandably back then!). Why was this behavior broken?

    Reply

Leave a Reply to Jason Cancel reply

Your email address will not be published. Required fields are marked *