Sync shared code with aspnetcore for HTTP/3

[jkotalik]

@scalablecory / @Tratcher I removed the OS check for IsQuicSupport for now; I was hitting issues where the version in aspnetcore didn't match the version in runtime. @Tratcher also had pushback on this check in general. We can discuss what we'd like to do here.

[scalablecory]

What is @Tratcher's concern? I would prefer to just fix it rather than remove.

[Tratcher]

Cory
#32575

[Tratcher]

Without this check, what's the error you get from any earlier version of Windows? Does it just fail on the next new MsQuicApi() with a NotSupportedException?

[scalablecory]

Cory
#32575

Indeed, I'd rather fix that than get rid of it. @jkotas's suggestion is exactly what I had in mind and I bet there's some P/invoke signature for that somewhere in corefx already that we can use.

Without this check, what's the error you get from any earlier version of Windows? Does it just fail on the next new MsQuicApi() with a NotSupportedException?

No, and that's the problem. msquic fails with unspecified error codes at unspecified points (whenever it tries to use TLS for the first time, who knows when that is... probably when it connects) when platform support is not there, and the error codes are different depending on the platform it targets. Not very useful behavior from a library.

We know TLS 1.3 is required, and so we can check for TLS 1.3 availability (I'm sitting on a patch to do that), but it also requires additional APIs beyond just basic TLS 1.3 support, so we can't leave it there.

My goal is to fast-fail with a useful messages for users, and I'm hoping msquic is enhanced in the future so we can remove the check all together.

[Tratcher]

As long as the fail-fast is accurate.

[stephentoub]

I bet there's some P/invoke signature for that somewhere in corefx already that we can use.

RuntimeInformation.OSDescription:

runtime/src/libraries/System.Runtime.InteropServices.RuntimeInformation/src/System/Runtime/InteropServices/RuntimeInformation/RuntimeInformation.Windows.cs

Line 22 in e1441aa

public static string OSDescription => s_osDescription ??= Interop.NtDll.RtlGetVersion();

wraps a (wrapper to a) P/Invoke to it:

runtime/src/libraries/Common/src/Interop/Windows/NtDll/Interop.RtlGetVersion.cs

Lines 11 to 12 in 4f9ae42

	[DllImport(Libraries.NtDll, ExactSpelling = true)]
	private static extern int RtlGetVersion(ref RTL_OSVERSIONINFOEX lpVersionInformation);

[Tratcher]

Can we merge this as is to get the shared source back in sync and address #32575 separately?

[jkotalik]

A few things:

• If we are using msquic with stub tls, we wouldn't need an updated version of Windows. You really only need this when using schannel. I constantly needed to uncomment this check when using stub tls. Maybe we can fix this via an app context switch or something like that.
• This check doesn't work in Kestrel which I need clarification on. https://github.com/dotnet/runtime/pull/32779/files#diff-0482602b7073d6fa3fa809fa90d9130dL144. Why does Environment.OSVersion return different values between AspNetCore and Runtime?
• Right now, as the System.Net.Quic code is shared between Kestrel and Runtime, pinvoking is a bit more annoying.

[jkotalik]

I'm with @Tratcher here, I'd rather unblock Kestrel from using msquic in general (stub or tls) and figure out a better fix in a follow up PR.

[scalablecory]

If we are using msquic with stub tls

I don't think this is a scenario we should support. It is no longer "QUIC" in that case, and so QUIC is indeed "not supported".

Right now, as the System.Net.Quic code is shared between Kestrel and Runtime, pinvoking is a bit more annoying.

How so?