Open deeprobin opened 1 year ago
This is an interesting report. the SocketsHttpHandler that we use by default has UseProxy
set to true, which then uses the default IWebProxy to actually proxy requests. From the docs:
The default instance returned by this property will initialize following a different set of rules depending on your platform:
For Windows: Reads proxy configuration from environment variables or, if those are not defined, from the user's proxy settings.
For macOS: Reads proxy configuration from environment variables or, if those are not defined, from the system's proxy settings.
For Linux: Reads proxy configuration from environment variables or, in case those are not defined, this property initializes a non-configured instance that bypasses all addresses.
This sounds like exactly the behavior I'd expect.
In what way can I provide more information so we can find the root cause?
I'm not very well-versed with proxy configuration on HttpClient myself, but the API docs for this are here - you may be able to write a small utility to investigate and compare. My belief based on docs is that the .NET runtime should be using the user-level proxy settings configuration already, but I don't have one set up and so cannot easily verify this.
Describe the bug
I want to publish a Docker image behind a corporate proxy using
dotnet publish
.I had to find out, however, that the proxy settings (via for example) Windows are not taken into account.
Since many larger companies use a proxy to regulate the traffic, I will not be the only one who has this problem.
I am aware that you can set HTTP_PROXY and HTTPS_PROXY with the proxy address as the default environment variable in the docker configuration, but in my opinion this is also not the best choice for security reasons, since the credentials have to be passed as plain text and are not stored in the Windows Credential Manager.
I would like the default system proxy to be considered for the build of the Docker image.
To Reproduce
Create a project with native container support
Setup a proxy / use a corporate proxy
Work behind a firewall, which blocks any traffic that does not go through the proxy
dotnet publish --os linux --arch x64 /t:PublishContainer -c Release
Exceptions (if any)
Error MSB4081: The "CreateNewImage" task failed unexpectedly. Timeout to mcr.microsoft.com:443
It should be possible to reproduce this bug. If necessary, I can send a binary log.
Further technical details
dotnet --info
Not relevant, but VS Professional 2022 / Latest version