runtime: .NET Core 2.1 SocketsHttpHandler proxy authentication using Windows auth is broken

When being behind a proxy requesting authentication, .net core 2.1 HttpClientHandler fails to properly authenticate against the proxy. The following code is working in .net core 2.0 but doesn’t work anymore with .net core 2.1:

            var handler = new HttpClientHandler();
            handler.DefaultProxyCredentials = CredentialCache.DefaultCredentials;

            var client = new HttpClient(handler);
            var response = client.GetAsync("https://www.mocky.io/v2/5185415ba171ea3a00704eed").GetAwaiter().GetResult();
            var content = response.Content.ReadAsStringAsync().GetAwaiter().GetResult();

About this issue

Original URL
State: closed
Created 6 years ago
Comments: 68 (38 by maintainers)

Most upvoted comments

I’ve experienced the same issue with proxy authentication in Windows 10 with a proxy autoconfigured via a pac file.

In 2.0 this code works.

var handler = new HttpClientHandler();
handler.DefaultProxyCredentials = CredentialCache.DefaultCredentials;

It doesn’t work in 2.1, regardless of whether ‘System.Net.Http.UseSocketsHttpHandler’ is true or false, although an exception is thrown if it is false.

I’ve tried a few combination of settings to get proxy authentication to work in 2.1. The code below was the only thing that appeared to work. Not ideal as the proxy settings had to be specified explicitly.

AppContext.SetSwitch("System.Net.Http.UseSocketsHttpHandler", false);
var httpClient = new HttpClient(
new HttpClientHandler()
{
	Proxy = new WebProxy("http://proxy:8080") { UseDefaultCredentials = true }
});

dyamo on Jun 7, 2018

.DefaultCredentials works with .net core 2.0 but not with .net core 2.1. I think there is a regression bug.

In the short term, you might want to opt-out of the new SocketsHttpHandler HTTP stack in .NET Core 2.1.

See the release notes for instructions on switching back to the HTTP stack (WinHttpHandler for Windows) that was used in .NET Core 2.0:

https://github.com/dotnet/core/blob/master/release-notes/2.1/2.1.0.md

Adding a line of code like this to your app will switch you back to the .NET Core 2.0 HTTP stack:

AppContext.SetSwitch(“System.Net.Http.UseSocketsHttpHandler”, false);

davidsh on Jun 6, 2018

I have experienced similar issues with HttpClient after we upgraded to ASP Net Core 2.1. Bu only with few (1 or 2) calls to some of our company-internal API’s.

This:

AppContext.SetSwitch("System.Net.Http.UseSocketsHttpHandler", false);

solved our issues. Though, is this a temporary quick-solution?

sabiland on Jun 13, 2018

In case anyone else runs in to this, using HttpClient to call out to WEBAPIs inside of IIS was causing the error:

HttpRequestException: Response status code does not indicate success: 403 (This URL is not allowed to be proxied)

When troubleshooting with Fiddler, the error would go away and everything would work fine.

Solution was to add the following to startup.cs: AppContext.SetSwitch("System.Net.Http.UseSocketsHttpHandler", false);

tolgabalci on Mar 22, 2019

3rd party libraries

This also includes the Azure WebJobs SDK. I was never able to get it running behind our evil company proxy (System.Net.Http.UseSocketsHttpHandler does not work). For several years .Net Core is an endless source of frustration. 👎

JohannesHoppe on Oct 2, 2018

@karelz thanks for pointing out that I am mixing a different topic to this proxy only issue, adding a new issue about SPNego.

CJHarmath on Sep 17, 2018

Ok, I understand it is a temporary solution.

For now I can say only, that the problem was only when calling one (among many others) in-house API’s. The result was always timeout (“…Task was cancelled…”). So Exception message didn’t provide any extra info.

How could I check what exactly was the problem? OK, I’ll check dotnet/corefx#30166.

sabiland on Jun 14, 2018

@tebeco proxy support in SocketsHttpHandler came in quite late (to support also enterprise scenarios). We tested NTLM and Basic, but we couldn’t get easily to Kerberos proxy authentication setup. That’s why it slipped through. Automated testing of these setups are fairly involved and costly. It is a known test gap we have 😦 … we started investing into it quite recently, so I hope we will be soon in position to protect against regressions in the space.

karelz on Jun 12, 2018

how did we end up with surprise like this ? i mean entreprise context and proxy is kind frequent no ?

tebeco on Jun 12, 2018