How to set Proxy Address for Http & Https bindings

[epignosisx]

I'm trying to set a proxy address and credentials to an Https binding but I have not find a way. Do you have some documentation or can you provide a code snippet on how to do it?

[hongdai]

I don't think custom proxy address is currently supported. The default proxy is used.

Does it block your scenario?

[epignosisx]

Yes. We have a corporate proxy that is blocking the requests and we have to set the proxy address & credentials (not default) in order to get pass it.

Is there a way to get around this limitation?

[hongdai]

It's supported to set a non default credential, see the code example https://github.com/dotnet/wcf/blob/master/src/System.Private.ServiceModel/tests/Scenarios/Security/TransportSecurity/Negotiate/NegotiateStream_Http_Tests.4.1.0.cs#L121

The default proxy should work for the machines on your corporate. Could you give a try?

[epignosisx]

Thanks @hongdai. I tried to configure it like the example you provided but it did not work. I keep getting:

The remote server returned an unexpected response: (407) Proxy Authentication Required

We have always had to specify the proxy address in other apps, but I do not see a way of doing it here. For HttpClient which is what WCF uses under the covers we would need to set the Proxy property:

var httpClientHandler = new HttpClientHandler {
    Proxy = new MyProxy() //MyProxy implements IWebProxy
};

but I do not find an extensibility point to provide the proxy settings.

[mconnew]

@epignosisx, can you verify that using HttpClientHandler in that way works for you in your network environment and you can make successful calls? Due to backwards compatibility requirements, some of the properties on HttpClientHandler on some platforms are noop's. If this works for you, then we can add the WCF proxy api to our contract surface and wire the property through. Depending on timing, we might be able to get this done for the 1.1 RTM release (but there's no guarantee so this isn't a hard commitment), otherwise you could use a development build of WCF.

[epignosisx]

I can confirm that assigning an implementation of IWebProxy to HttpClientHandler allows network calls to go through the company proxy. We have a few integrations with external restful services using HttpClient with our proxied HttpClientHandler and works great. We have tested it in Windows 7 & Windows Server 2012 R2.

It would be great if it can make it to 1.1 RTM. This is an impediment for anyone behind a corporate proxy. We had to resort to crafting the SOAP envelope manually.

I can help test a build.

[moliveto]

@epignosisx you can provide us an a sample how to set HttpClientHandler to WCF client?

[epignosisx]

Hi folks. I noticed this got moved from 2.0 to future. This is a pretty big blocker for any customer behind an authenticated proxy. I'm surprised you haven't heard more about this issue from other people.

Is there any chance of considering putting this back on 2.0?

[zhenlan]

Hi @epignosisx this issue is still in 2.0.0 milestone. We will try but depending on how much cycles @mconnew has as the door for 2.0.0 is closing very fast.

[epignosisx]

Great to hear! Some further ideas on the issue:

It would be great if an application could participate in the creation of the HttpClients. This would not only give us a chance to configure the HttpClientHandler's proxy, but also add additional DelegatingHandlers that we may use. For example to skip the network call and return canned responses (great for mocking external services).

[mconnew]

@epignosisx , the limitation we have is we can't add an api which isn't available on the full framework. On the full framework, we use HttpWebRequest so it would be quite a lot of work to make a delegating handler work with HttpWebRequest in a reliable clean way.
It's definitely a nice feature ask and we might be able to accommodate it in the future via some api agnostic mechanism. Off the top of my head, maybe we could add some support for adding something to the BindingParameterCollection used when creating a ChannelFactory. The question though is what? We create a new instance of HttpClientHandler for each remote hostname/credentials combination to prevent any security issues with cached credentials for one request being used for a different request which needs different credentials. This means we need to be able to instantiate the DelegatingHandler inside WCF on demand. There's also the issue that we set a bunch of properties on the HttpClientHandler and there's no guarantee that a pre-constructed DelegatingHandler has an HttpClientHandler at it's root. Also on UWP we don't even use HttpClientHandler and have our own implementation in order to make Certificate authentication work.
So this means we need some kind of factory mechanism where we pass our constructed HttpMessageHandler to which then returns the DelegatingHandler. We could do this by looking for a Func<DelegatingHandler, HttpMessageHandler> in the BindingParamterCollection, but this feels really dirty/hacky from an API design perspective.
Feel free to open an issue on this as a feature request, but supporting additional DelegatingHandler's isn't going to get done for 2.0.0 as it needs a thorough design discussion.

[epignosisx]

Can't argue with the points you brought up. I didn't account for the Full Framework or UWP. It is definitely tricky to accommodate this feature when there are 3 different ways of making HTTP calls.

I'll open the issue. For now I'm happy with having the ability to specify proxy settings somehow.

[mconnew]

@epignosisx, proxy support has been checked in. It has only had basic manual validation at this point but you should be able to pick up a build with support from the myget dev feeds tomorrow. This only supports running on windows at the moment.

[zhenlan]

Move the *nix support to post 2.0. @epignosisx please let us know if this is important to you.

[epignosisx]

Thanks folks for working on this. Linux support is not a priority for me.

[mconnew]

@epignosisx, were you able to verify this works for you on windows?

[Dudod]

Hi all. I have problem with configure proxy for http binding in .net core 2.0.
My code:

var binding = new BasicHttpBinding();
{
ProxyAddress = new Uri("http://192.168.0.1:8080"),
UseDefaultWebProxy = false
};
EndpointAddress endpoint = new EndpointAddress("http://someendpoint.com/SomeService");
_channelFactory = new ChannelFactory(binding, endpoint);
IClientChannel proxy = (IClientChannel)_channelFactory.CreateChannel();
TResult result;
try
{
result = await serviceCall((T)proxy).ConfigureAwait(false);
return result;
}
catch(Exception)
{
proxy.Abort();
return default(TResult);
}

After call service i have Exception: "When using a non-null Proxy, the WindowsProxyUsePolicy property must be set to WindowsProxyUsePolicy.UseCustomProxy." But i can`t set this property. In .net core 1.0 this code work correctly. How i can do it? Maybe i use it wrong?

[Dudod]

I have investigation about this problem. Important nootice - I talk about windows. I think problem in ServiceModelHttpMessageHandler used in WCF for Win. It wrapper for WinHttpHandler. Key difference between it and HttpClientHandler used in Unix build - it not set WindowsProxyUsePolicy.UseCustomProxy in case use proxy.

[zminic]

Hi, I have a strange problem with BasicHttpBinding and proxy settings that is probably related to this issue.

The situation in our company is that we used to have corporate proxy and then at some point they removed it. We removed proxy from all windows settings and everything works as expected except WCF calls. WCF somehow still wants to use proxy even if there is no proxy configured in windows (also cleared automatic proxy detection from windows).

Opening urls in browser works, using HttpClient from aspnet core works, only WCF calls throw exception:

"WinHttpException: The server name or address could not be resolved", I have verified in wireshark that there is request for DNS resolve of old proxy, even if it is not configured anywhere.

Then I tried to set UseDefaultWebProxy on BasicHttpBinding to false and then I get following error:

"InvalidOperationException: When using a non-null Proxy, the WindowsProxyUsePolicy property must be set to WindowsProxyUsePolicy.UseCustomProxy."

I should also mention that when using VPN to access my workplace connections succeed.

Do you have a hint why is this happening and why only WCF calls require old proxy even if it is not configured anywhere?

[mconnew]

@zminic, HttpClient in .Net Core doesn't use WinINet which picks up its proxy settings from the same place as you configure IE/Edge proxy settings. It uses WinHTTP instead which maintains its own proxy settings. From an administrative command prompt execute the command netsh winhttp reset proxy to reset WinHTTP to use direct connections instead. If you want to see what it's currently set as, execute the command netsh winhttp show proxy before you modify it. It looks like your IT department probably missed resetting this configuration when getting rid of the proxy.

[zminic]

@mconnew Thanks a lot! It worked. Didn't know that .Net core uses different proxy settings.

[mconnew]

The fix for broken proxy usage will be in the preview 1 release for .Net Core 2.1

[ctaggart]

Based on this thread, to proxy to Fiddler on Windows 10, I used these commands as admin:

netsh winhttp show proxy
netsh winhttp set proxy 127.0.0.1:8888
netsh winhttp reset proxy

On Linux, is http_proxy environment variable supported? I guess I'll find out.

[mconnew]

@ctaggart, in your use case WCF is configuring HttpClientHandler to use the default proxy. The behavior of what that means on Linux is a question for the dotnet/corefx repo as we don't do anything special there.