[release/2.1] Fix HttpWebRequest when using system proxy settings #31123
Conversation
While investigating other HttpClient/HttpWebRequest proxy-related bugs, I discovered that HttpWebRequest was not honoring system proxy settings as defined on Windows with IE settings or on Linux using environment variables. The problem is due to how HttpClient and HttpWebRequest differ in how they represent the default behavior of using system proxy settings with the various properties. Fixed HttpWebRequest so that it will translate the system proxy settings to the internal HttpClient/HttpClientHandler objects. I also removed an invalid Assert in HttpConnection. This assert was firing when using a proxy that was defined on the loopback adapter using IPv6 literal "[::1]". Due to issue #28863 with Uri, the Uri.IdnHost property doesn't have the brackets for IPv6 literals. So, the Assert was occuring. I did not add any new CI tests because it is currently not possible to test system proxy settings in CI since it involves changing machine configuration. But I ran manual tests.
davidsh
changed the title
|
@dotnet/dnceng The branch seems broken for building. Example: https://ci3.dot.net/job/dotnet_corefx/job/release_2.1/job/windows-TGroup_netfx+CGroup_Release+AGroup_x86+TestOuter_false_prtest/279/console
|
|
@davidsh generally someone from the CoreFX team will be expected to fix branch-specific build breaks, but on behalf of dnceng I'm taking a look and will see if I can find an owner for this. |
|
@davidsh perusing the logs I don't think this is your doing but the branch does actually appear to be broken on some kind of problem with repo build. This needs to be handled by the product teams, but if anything infrastructure falls out of it we'll be on point to help. |
davidsh
added
Servicing-consider
|
I'm taking a look at the CI failure as it seems like something weird is happening with the sync command. |
|
#31139 should fix the CI issue. |
|
@dotnet-bot test this please |
|
@davidsh looks like you have a test failure. |
We've seen this fail randomly before. It is unlikely caused by this PR since this test is not affected by the PR. We suspect this is a test bug. I'll re-run the tests. |
|
@dotnet-bot Test Windows x86 Release Build |
|
@dotnet-bot test Outerloop Windows x64 Debug Build |
|
Current failures in CI are known test bugs. |
danmoseley
added
the
* NO MERGE *
davidsh
removed
the
* NO MERGE *
|
|
@davidsh I am running |
This particular bug will be fixed in .NET Core Runtime 2.1.4 which hasn't been released yet. See: https://www.microsoft.com/net/download/dotnet-core/2.1 There are other proxy related bugs that will be fixed in 2.1.5 as well. |
While investigating other HttpClient/HttpWebRequest proxy-related bugs, I discovered that
HttpWebRequest was not honoring system proxy settings as defined on Windows with IE
settings or on Linux using environment variables.
The problem is due to how HttpClient and HttpWebRequest differ in how they represent
the default behavior of using system proxy settings with the various properties. Fixed
HttpWebRequest so that it will translate the system proxy settings to the internal
HttpClient/HttpClientHandler objects.
I also removed an invalid Assert in HttpConnection. This assert was firing when using a proxy
that was defined on the loopback adapter using IPv6 literal "[::1]". Due to issue #28863 with Uri,
the Uri.IdnHost property doesn't have the brackets for IPv6 literals. So, the Assert was
occuring.
I did not add any new CI tests because it is currently not possible to test system proxy settings
in CI since it involves changing machine configuration. But I ran manual tests.
Fixes #31122