some small proxy-related fixes #50770
Conversation
|
Tagging subscribers to this area: @dotnet/ncl Issue DetailsDon't apply the max connections limit for ProxyConnect connections (i.e. the CONNECT we make to the proxy to create a proxy tunnel). The max connections limit is still applied for the user of the tunnel, which is where it makes sense. Also, fix some logic with NT proxy auth where we could have tried to perform proxy authentication against an origin server if the origin server sent us a 407 (proxy auth challenge). The logic is now consistent with the HTTP proxy auth. Add relevant tests and do some test cleanup. Fixes #48363
|
|
/azp run runtime-libraries-coreclr outerloop |
| } | ||
|
|
||
| [Fact] | ||
| public async Task ProxyTunnelRequest_MaxConnectionsSetButDoesNotApplyToProxyConnect_Success() |
There was a problem hiding this comment.
Should we set the pool idle timeout to infinite here? I assume the failure condition for this test relies on
being larger than
otherwise it could pass even without this change (after the first pool expired)
There was a problem hiding this comment.
We accept both connections before sending the responses. So it shouldn't matter.
src/libraries/System.Net.Http/src/System/Net/Http/SocketsHttpHandler/HttpConnectionPool.cs
Outdated
Show resolved
Hide resolved
|
/azp run runtime-libraries-coreclr outerloop |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
/azp run runtime-libraries-coreclr outerloop |
|
Azure Pipelines successfully started running 1 pipeline(s). |
|
There are a bunch of CI legs that have been queued for a very long time. @dotnet/dnceng any idea what's up here? |
|
Hi @geoffkizer. If these are windows jobs, they are likely related to the issues with the buildpool.windows.10.amd64.vs2019.open scale set that we are having. Issue is tracked here and here. |
|
/azp run runtime-libraries-coreclr outerloop |
|
Azure Pipelines successfully started running 1 pipeline(s). |
ghost
locked as resolved and limited conversation to collaborators
Don't apply the max connections limit for ProxyConnect connections (i.e. the CONNECT we make to the proxy to create a proxy tunnel). The max connections limit is still applied for the user of the tunnel, which is where it makes sense.
Also, fix some logic with NT proxy auth where we could have tried to perform proxy authentication against an origin server if the origin server sent us a 407 (proxy auth challenge). The logic is now consistent with the HTTP proxy auth.
Add relevant tests and do some test cleanup.
Fixes #48363