Skip to content
This repository was archived by the owner on Jan 23, 2023. It is now read-only.

Fix WinHttpHandler when using authenticating proxies#30196

Merged
davidsh merged 1 commit intodotnet:masterfrom
davidsh:winhttp_proxy_auth
Jun 8, 2018
Merged

Fix WinHttpHandler when using authenticating proxies#30196
davidsh merged 1 commit intodotnet:masterfrom
davidsh:winhttp_proxy_auth

Conversation

@davidsh
Copy link
Contributor

@davidsh davidsh commented Jun 7, 2018

This was a regression from .NET Core 2.0 due to PR #28105.

Proxy authentication using system default proxy settings that involve a PAC file
(either autodiscovery or explicit PAC file) cause a NullReferenceException in WinHttpHandler in the
CheckResponseForAuthentication() method.

This problem is only discovered when using an authenticating proxy server (any auth scheme) that is
discovered using PAC files. This is considered the "system default" proxy. When this occurs, the
handler's Proxy property is null and dereferencing it caused the exception.

Due to the problems described in #6997, the uri of the proxy can't be determined yet since it is only
known to WinHTTP. Fixing #6997 is complicated and impacts performance. However, in most cases, as
long as the credentials are a NetworkCredential object, knowing the uri of the proxy is not needed.

I tested this manually using the steps I described in #30191. I did not add any tests to this PR since
they can't be run in CI. However, I am working on a task that will eventually add Enterprise-Scenario
testing like this (PAC files, authenticating proxies, etc.) to our systems.

Fixes #30191
Contributes to #6997

This was a regression from .NET Core 2.0 due to PR #28105.

Proxy authentication using system default proxy settings that involve a PAC file
(either autodiscovery or explicit PAC file) cause a NullReferenceException in WinHttpHandler in the
CheckResponseForAuthentication() method.

This problem is only discovered when using an authenticating proxy server (any auth scheme) that is
discovered using PAC files. This is considered the "system default" proxy. When this occurs, the
handler's Proxy property is null and dereferencing it caused the exception.

Due to the problems described in #6997, the uri of the proxy can't be determined yet since it is only
known to WinHTTP. Fixing #6997 is complicated and impacts performance. However, in most cases, as
long as the credentials are a NetworkCredential object, knowing the uri of the proxy is needed.

I tested this manually using the steps I described in #30191. I did not add any tests to this PR since
they can't be run in CI. However, I am working on a task that will eventually add Enterprise-Scenario
testing like this (PAC files, authenticating proxies, etc.) to our systems.

Fixes #30191
Contributes to #6997
@davidsh davidsh added this to the 3.0 milestone Jun 7, 2018
@davidsh davidsh self-assigned this Jun 7, 2018
@davidsh davidsh requested review from a team and stephentoub June 7, 2018 19:30
@davidsh
Copy link
Contributor Author

davidsh commented Jun 7, 2018

@dotnet-bot test Outerloop Windows x64 Debug Build

Copy link
Contributor

@rmkerr rmkerr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Thanks for fixing this.

Copy link
Member

@wfurt wfurt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM.

@davidsh
Copy link
Contributor Author

davidsh commented Jun 7, 2018

@dotnet-bot test Outerloop Windows x64 Debug Build

@davidsh
Copy link
Contributor Author

davidsh commented Jun 8, 2018

@davidsh davidsh merged commit 69c2e20 into dotnet:master Jun 8, 2018
@davidsh davidsh deleted the winhttp_proxy_auth branch June 8, 2018 00:31
picenka21 pushed a commit to picenka21/runtime that referenced this pull request Feb 18, 2022
…0196)

This was a regression from .NET Core 2.0 due to PR dotnet/corefx#28105.

Proxy authentication using system default proxy settings that involve a PAC file
(either autodiscovery or explicit PAC file) cause a NullReferenceException in WinHttpHandler in the
CheckResponseForAuthentication() method.

This problem is only discovered when using an authenticating proxy server (any auth scheme) that is
discovered using PAC files. This is considered the "system default" proxy. When this occurs, the
handler's Proxy property is null and dereferencing it caused the exception.

Due to the problems described in dotnet/corefx#6997, the uri of the proxy can't be determined yet since it is only
known to WinHTTP. Fixing dotnet/corefx#6997 is complicated and impacts performance. However, in most cases, as
long as the credentials are a NetworkCredential object, knowing the uri of the proxy is needed.

I tested this manually using the steps I described in dotnet/corefx#30191. I did not add any tests to this PR since
they can't be run in CI. However, I am working on a task that will eventually add Enterprise-Scenario
testing like this (PAC files, authenticating proxies, etc.) to our systems.

Fixes dotnet/corefx#30191
Contributes to dotnet/corefx#6997

Commit migrated from dotnet/corefx@69c2e20
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants