HttpClient.SendAsync Throws Two Exceptions When QUIC Is Not Supported

[brianrob]

On first use of HttpClient, there is a check to see if QUIC is supported. On any machine where QUIC hasn't been setup, this code throws two exceptions - a DLLNotFoundException, which is caught, and translated into a NotSupportedException. The NotSupportedException is also caught and translated into IsSupported = true. This is the stack where this happens:

module coreclr   <<coreclr!ProcessCLRException>>
module ntdll   <<ntdll!RtlRaiseException>>
module   kernelbase <<kernelbase!RaiseException>>
module coreclr <<coreclr!IL_Throw>>
system.net.quic!System.Net.Quic.Implementations.MsQuic.Internal.MsQuicApi..ctor()
module coreclr <<coreclr!ProcessCLRException>>
module ntdll <<ntdll!RtlUnwind>>
module coreclr <<coreclr!ProcessCLRException>>
module ntdll <<ntdll!RtlRaiseException>>
module kernelbase <<kernelbase!RaiseException>>
module coreclr <<coreclr!ThePreStub>>
system.net.quic!System.Net.Quic.Implementations.MsQuic.Internal.MsQuicApi..ctor()
system.net.quic!System.Net.Quic.Implementations.MsQuic.Internal.MsQuicApi..cctor()
module coreclr <<coreclr!DelayLoad_Helper>>
system.net.quic!MsQuicImplementationProvider.get_IsSupported
system.net.http!System.Net.Http.HttpConnectionPool..ctor(System.Net.Http.HttpConnectionPoolManager,   System.Net.Http.HttpConnectionKind, System.String, Int32, System.String,   System.Uri, Int32)
system.net.http!HttpConnectionPoolManager.SendAsyncCore
system.net.http!HttpConnectionPoolManager.SendAsync
system.net.http!HttpConnectionHandler.SendAsync
system.net.http!System.Net.Http.RedirectHandler+<SendAsync>d__4.MoveNext()
module System.Private.CoreLib.il   <<System.Private.CoreLib.il!System.Runtime.CompilerServices.AsyncValueTaskMethodBuilder`1[System.__Canon].Start(!!0&)>>
system.net.http!RedirectHandler.SendAsync
system.net.http!HttpMessageHandlerStage.SendAsync
system.net.http!SocketsHttpHandler.SendAsync
system.net.http!DelegatingHandler.SendAsync
system.net.http!System.Net.Http.DiagnosticsHandler+<SendAsyncCore>d__5.MoveNext()
module System.Private.CoreLib.il   <<System.Private.CoreLib.il!System.Runtime.CompilerServices.AsyncValueTaskMethodBuilder`1[System.__Canon].Start(!!0&)>>
system.net.http!DiagnosticsHandler.SendAsyncCore
system.net.http!DiagnosticsHandler.SendAsync
system.net.http!HttpClientHandler.SendAsync
system.net.http!HttpMessageInvoker.SendAsync
system.net.http!System.Net.Http.HttpClient+<<SendAsync>g__Core\|83_0>d.MoveNext()
module System.Private.CoreLib.il <<System.Private.CoreLib.il!System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1[System.__Canon].Start(!!0&)>>
system.net.http!System.Net.Http.HttpClient.<SendAsync>g__Core\|83_0(System.Net.Http.HttpRequestMessage,   System.Net.Http.HttpCompletionOption,   System.Threading.CancellationTokenSource, Boolean,   System.Threading.CancellationTokenSource, System.Threading.CancellationToken)
system.net.http!HttpClient.SendAsync

Given that this is a light-up scenario, and in most cases, QUIC won't be supported, we should change this behavior to not throw, but instead, to detect the existence of the native component (e.g. msquic.dll) before attempting to load it.

[ghost]

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

Issue Details

---

Description

On first use of HttpClient, there is a check to see if QUIC is supported. On any machine where QUIC hasn't been setup, this code throws two exceptions - a DLLNotFoundException, which is caught, and translated into a NotSupportedException. The NotSupportedException is also caught and translated into IsSupported = true. This is the stack where this happens:

module coreclr   <<coreclr!ProcessCLRException>>
module ntdll   <<ntdll!RtlRaiseException>>
module   kernelbase <<kernelbase!RaiseException>>
module coreclr <<coreclr!IL_Throw>>
system.net.quic!System.Net.Quic.Implementations.MsQuic.Internal.MsQuicApi..ctor()
module coreclr <<coreclr!ProcessCLRException>>
module ntdll <<ntdll!RtlUnwind>>
module coreclr <<coreclr!ProcessCLRException>>
module ntdll <<ntdll!RtlRaiseException>>
module kernelbase <<kernelbase!RaiseException>>
module coreclr <<coreclr!ThePreStub>>
system.net.quic!System.Net.Quic.Implementations.MsQuic.Internal.MsQuicApi..ctor()
system.net.quic!System.Net.Quic.Implementations.MsQuic.Internal.MsQuicApi..cctor()
module coreclr <<coreclr!DelayLoad_Helper>>
system.net.quic!MsQuicImplementationProvider.get_IsSupported
system.net.http!System.Net.Http.HttpConnectionPool..ctor(System.Net.Http.HttpConnectionPoolManager,   System.Net.Http.HttpConnectionKind, System.String, Int32, System.String,   System.Uri, Int32)
system.net.http!HttpConnectionPoolManager.SendAsyncCore
system.net.http!HttpConnectionPoolManager.SendAsync
system.net.http!HttpConnectionHandler.SendAsync
system.net.http!System.Net.Http.RedirectHandler+<SendAsync>d__4.MoveNext()
module System.Private.CoreLib.il   <<System.Private.CoreLib.il!System.Runtime.CompilerServices.AsyncValueTaskMethodBuilder`1[System.__Canon].Start(!!0&)>>
system.net.http!RedirectHandler.SendAsync
system.net.http!HttpMessageHandlerStage.SendAsync
system.net.http!SocketsHttpHandler.SendAsync
system.net.http!DelegatingHandler.SendAsync
system.net.http!System.Net.Http.DiagnosticsHandler+<SendAsyncCore>d__5.MoveNext()
module System.Private.CoreLib.il   <<System.Private.CoreLib.il!System.Runtime.CompilerServices.AsyncValueTaskMethodBuilder`1[System.__Canon].Start(!!0&)>>
system.net.http!DiagnosticsHandler.SendAsyncCore
system.net.http!DiagnosticsHandler.SendAsync
system.net.http!HttpClientHandler.SendAsync
system.net.http!HttpMessageInvoker.SendAsync
system.net.http!System.Net.Http.HttpClient+<<SendAsync>g__Core\|83_0>d.MoveNext()
module System.Private.CoreLib.il <<System.Private.CoreLib.il!System.Runtime.CompilerServices.AsyncTaskMethodBuilder`1[System.__Canon].Start(!!0&)>>
system.net.http!System.Net.Http.HttpClient.<SendAsync>g__Core\|83_0(System.Net.Http.HttpRequestMessage,   System.Net.Http.HttpCompletionOption,   System.Threading.CancellationTokenSource, Boolean,   System.Threading.CancellationTokenSource, System.Threading.CancellationToken)
system.net.http!HttpClient.SendAsync

Given that this is a light-up scenario, and in most cases, QUIC won't be supported, we should change this behavior to not throw, but instead, to detect the existence of the native component (e.g. msquic.dll) before attempting to load it.

Author:	brianrob
Assignees:	-
Labels:	area-System.Net, tenet-performance, untriaged
Milestone:	-

[ManickaP]

@brianrob: Did you have System.Net.SocketsHttpHandler.Http3DraftSupport app context switch on? What is your scenario? Are you running some tests locally (which ones) or is this CI or when/where did you see this? Is this blocking something/someone? What's the priority?

I'm trying to understand this since me and @CarnaViire are taking over H3 and QUIC so that we do not make the same mistake in the future.

[stephentoub]

Did you have System.Net.SocketsHttpHandler.Http3DraftSupport app context switch on?

@ManickaP, it's defaulting to on:

runtime/src/libraries/System.Net.Http/src/System/Net/Http/SocketsHttpHandler/HttpConnectionSettings.cs

Lines 173 to 174 in 766fec7

	// Default to allow.
	return true;

[brianrob]

Right, per @stephentoub's comment, I did not have the switch on, but it defaults to true. The scenario where I ran into this is running dotnet build, which uses HttpClient for sending telemetry, but this will occur in any app that is using HttpClient.

I would describe the priority as not urgent, but something that we should fix in .NET 6, as this is extra overhead in any app using HttpClient. Throwing and catching exceptions are expensive, and given that all of this detection code is internal, and we don't want the exception to leak, we can do this without exceptions much more inexpensively.

[ManickaP]

I completely missed the PR that changed that and thought it was disabled by default. Thanks for pointing that out. And thanks for the additional info and use case.

[brianrob]

Thank you @stephentoub!