Specific Win10/11 Proxysettings cause wrong result in WebRequest.DefaultWebProxy.GetProxy(...)

[ole1986]

Description

Believe it or not!

I noticed when running .NET 6 Framework on Win10 Build 1905.3324 with VS 2022 17.6.5 it seem to be important that the URL given in the System -> Proxysetting does not contain any "http://" prefixes in the address field.

As long as Proxysetting is stored with "http://", the following code always returns NULL instead of the proxy Uri

WebRequest.DefaultWebProxy.GetProxy("https://google.de")

Reproduction Steps

1. create a simple console app with WebRequest.DefaultWebProxy.GetProxy("https://google.de") to return
2. Configure the Win10 System -> Proxysettings to contain "http://" in the address field (E.g. Address: http://proxy.fqdn.local Port: 3128) and keep the proxy exceptions empty
3. Enable and save the Proxysettings
4. Run the console app and expect a NULL to be returned from GetProxy(...) method

Expected behavior

WebRequest.DefaultWebProxy.GetProxy("https://google.de") should return the Proxy URL given in the Proxysettings of the system

Actual behavior

WebRequest.DefaultWebProxy.GetProxy("https://google.de") returns NULL

Regression?

I assume it worked on .NET 4.x since I used this framework version before migrating to .NET 6

Known Workarounds

NOW COME THE FUN PART

The workaround to use the very old "Internet option" which is still available in Win10

Since, the Proxy configuration from the "Internet options" dialog causes the proxy address to always be stored without "http://" prefix

Configuration

1. .NET 6
2. Win10 Build 1905.3324
3. x64 platform
4. Visual Studio 2022 17.6.5

Other information

No response

[ghost]

Tagging subscribers to this area: @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

Believe it or not!

I noticed when running .NET 6 Framework on Win10 Build 1905.3324 with VS 2022 17.6.5 it seem to be important that the URL given in the System -> Proxysetting does not contain any "http://" prefixes in the address field.

As long as Proxysetting is stored with "http://", the following code always returns NULL instead of the proxy Uri

WebRequest.DefaultWebProxy.GetProxy("https://google.de")

Reproduction Steps

1. create a simple console app with `WebRequest.DefaultWebProxy.GetProxy("https://google.de")`` to return
2. Configure the Win10 System -> Proxysettings to contain "http://" in the address field (E.g. Address: http://proxy.fqdn.local Port: 3128) and keep the proxy exceptions empty
3. Enable and save the Proxysettings
4. Run the console app and expect a NULL to be returned from GetProxy(...) method

Expected behavior

WebRequest.DefaultWebProxy.GetProxy("https://google.de") should return the Proxy URL given in the Proxysettings of the system

Actual behavior

WebRequest.DefaultWebProxy.GetProxy("https://google.de")` return NULL

Regression?

I assume it worked on .NET 4.x since I used this framework version before migrating to .NET 6

Known Workarounds

NOW COME THE FUN PART

The workaround to use the very old "Internet option" which is still available in Win10

Since, the Proxy configuration from the "Internet options" dialog causes the proxy address to always be stored without "http://" prefix

Configuration

1. .NET 6
2. Win10 Build 1905.3324
3. x64 platform
4. Visual Studio 2022 17.6.5

Other information

No response

Author:	ole1986
Assignees:	-
Labels:	area-System.Net, untriaged
Milestone:	-

[ole1986]

As a side note it might also be a simple OS bug, since the proxy configuration shows inconsistencies between "internet options" and "System -> Proxysettings"

[karelz]

@ole1986 can you try HttpClient.DefaultProxy instead? (WebRequest is obsolete for compat only and although it might be the same implementation behind it, let's stick with proper APIs)
Ideally try it on 7.0 or 8.0 Preview7 bits?
Are you able to reproduce the same problem on more than 1 machine in your environment?

Given that this is the first report, it is a bit suspicious.

[ghost]

This issue has been marked needs-author-action and may be missing some important information.

[ole1986]

@karelz Unfortunately not!

So whenever the registry value Computer\HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\Connections\DefaultConnectionSettings or Computer\HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows\CurrentVersion\Internet Settings\ProxyServer contains a "http://" prefix WebRequest.DefaultWebProxy.GetProxy([...]) and HttpClient.DefaultProxy([..]) returns NULL

To my surprise DefaultWebProxy and DefaultProxy actually translate the proxy url correctly in both cases (with/without "https://" prefix).

But .GetProxy([..]) only succeeded when not "http://" prefix is given in the ProxyServer REG_DWORD.

This is most properly the reason why the Internet option workaround does the trick

[ole1986]

An addtional fun part is. Even when I modify the registry value ProxyServer to contain the address without "http://". The next time I open the System -> Proxysettings the prefix takes place in the textbox.

Once I press save on the dialog, ProxyServer value will be overwritten to "http://(...)" which causes the issue with .GetProxy([..]) again

[ole1986]

I have tested in on simple console apps using VS 2022 with .NET 6 and VS 2019 with .NET 4.8

VS 2019 .NET 4.8 (no problem)

VS 2022 .NET 6 (problem occurred)

VS 2022 .NET 7 (problem occurred)

Running on the several machines

Attached all three projects here
ProxyNoIssueNET4.zip
ProxyIssueNET6.zip
ProxyIssueNET7.zip

[ole1986]

Since we are using ArcGIS Pro SDK 3.X we follow the recommendation to use .NET 6 according to ESRI recommendation
https://github.com/Esri/arcgis-pro-sdk/wiki#requirements

[karelz]

@ole1986 can you run your test in a HelloWorld console app in your environment? On .NET 7.0 and 8.0 Preview7 (or daily 8.0 builds)?
Then check if you can reproduce the same problem (in the console app) on more than 1 machine in your environment.

[ole1986]

Updated comment 1693070149 to contain .NET 7
Tested on several machines with same results

[fabeabe]

I can reproduce this with:

• VS 2019 .NET 4.8 (no problem)
• VS 2022 .NET 6 (problem occurred)

[karelz]

@ole1986 can you check with ArcGIS Pro SDK if .NET 7.0 is acceptable?
Is it left out from their supported versions just because they don't have time to support it or test it? Perhaps it is expected to just work ...
I also expect they have plans to support .NET 8.0 as soon as it will be out (November), right?

Paging @dotMorten if has insights here ...

[dotMorten]

Thanks @karelz . I work on a different SDK but will try and find who owns this part of the pro SDK. However since that SDK is for making plugins for a desktop product they probably don’t have the ability to move to .net7+.
It should be possible to try it in an external net7 app though although that won’t help a plug-in user.

[ole1986]

@dotMorten example projects are already to my comment for .net 4.8, 6.0 and 7.0

[ole1986]

What is the status regarding this issue?

[karelz]

The issue is rather confusing.

Originally, 7.0 was supposed to work fine. But it seems that it is not after all.
There seems to be a workaround, so it does not seem to be urgent.

Next steps I see:

• Try it on main (9.0) - reproduce it internally
• Analyze what is wrong and propose a fix (for main = 9.0)
• Based on the findings above + impact on customers, consider servicing it

I think we should be able to get to the next steps in a few weeks.

[wfurt]

This looks like dup of #38670, does it not?
as #38670 (comment) correctly stated, when the entry starts with http:// current implementation applies only to http traffic (and not https). That is different than what browsers do.