Authentication headers for HTTP Proxy are not sent proactively

[ptarjan]

Description

Context

In the https://claude.ai/code environment, the proxy doesn't work for dotnet restore. This is because dotnet restore expect the proxy to respond with an HTTP 407 before it sends the authentication headers, but this one does not.

Problem

When using an authenticated HTTP proxy configured via environment variables (HTTP_PROXY/HTTPS_PROXY with credentials in the URL), dotnet restore and other HttpClient-based operations fail with 401 Unauthorized.

Root cause: The current implementation waits for a 407 Proxy Authentication Required response before sending credentials. However, many proxies:

1. Return 401 Unauthorized instead of 407
2. Simply drop/timeout unauthenticated connections without any response
3. Close the connection after 407, making retry impossible for CONNECT tunnels

Reproduction:

export HTTPS_PROXY="http://user:password@proxy.example.com:8080"
dotnet restore  # Fails with 401 or timeout

Direct test showing the issue:

# Without Proxy-Authorization header:
CONNECT example.com:443 HTTP/1.1 → HTTP/1.1 401 Unauthorized
 
# With Proxy-Authorization header:
CONNECT example.com:443 HTTP/1.1
Proxy-Authorization: Basic dXNlcjpwYXNzd29yZA==
→ HTTP/1.1 200 OK

Solution

Modify AuthenticationHelper.SendWithProxyAuthAsync to proactively send Proxy-Authorization: Basic ... header on the first request when NetworkCredential is available, rather than waiting for a challenge.

This matches the behavior of curl, wget, and other HTTP clients that send proxy auth proactively.

Affected scenarios

• Corporate proxies requiring authentication
• Container environments with authenticated egress proxies
• CI/CD pipelines behind authenticated proxies

Reproduction Steps

1. Fork https://github.com/dotnet/runtime/
2. Open https://claude.ai/code
3. Choose "runtime" and type "run the tests" and choose "Full Internet" as the environment then press enter

Expected behavior

The tests run

Actual behavior

NuGet won't download

Regression?

No response

Known Workarounds

No response

Configuration

No response

Other information

No response

[dotnet-policy-service]

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

[wfurt]

For reference, there was some debate here: #100515
One can add the header easily for Basic auth, but I can see that is more difficult when using 3rd part tools where there is no control for the end user.

[dmitry-azaraev]

However, many proxies:

Is completely not true, most proxies doesnt do that, because it is just incorrect and must be considered as custom authentication scheme, which mimics to "Basic", but effectively is not.

401+Authentication header is dedicated to origin authentication, while 407+Proxy-Authentication dedicated to proxy authentication. They are must be separated because http proxies designed to work without tunnel in first place. Also http authentication by design is challenge based authentication, and user agent technically doesnt know how form auth header until challenged by server, while user agent doesnt know who asking credentials in proxy chain.

Popular browsers, for example, never send auth data proactively, more over in most cases is simply impossible, because they must ask credentials in dialog.

I'm complain only about formulation about most proxies.

In practice is not what bad to have "option", but you can implement this yourself: just connect to proxy as she want via sockets, establish tunnel, and integrate this to SocketsHttpClientHandler in ConnectCallback.

And also blame claude for using broken proxies.