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

/azp run runtime-libraries stress-http

Should we create test to verify that setting HTTP version to 3.0 will send correct/expected ALPN in handshake?

I was observing transport (msquic) failures with ALPN_NEG_FAILURE when I've updated Http3Connection to "h3" but not yet updated Http3LoopbackServer, so existing tests kind-of check that implicitly. But I'll see how to create more explicit test.

I am observing a lot of stress failures for HTTP/3 (but it's not like all of them fail). I don't know whether it was this change that regressed it or some other change. I would expect it to fail completely if it was this change, so I have doubts, but I will investigate.

is there need to update asp.net as well?

Re this:

does not with Chromium one (error CONNECTION_IDLE).

This seems super weird, any idea what's up here?

Stress regression is unrelated, shows on main, created an issue for that #56310

Should we create test to verify that setting HTTP version to 3.0 will send correct/expected ALPN in handshake?

@wfurt I wasn't able to come up with an idea on how to verify that explicitly. ALPN is hidden in QUIC handshake, isn't it? So I don't know how to intercept msquic to get that information... Do you have some ideas on how I could achieve that?

does not with Chromium one (error CONNECTION_IDLE).

This seems super weird, any idea what's up here?

@geoffkizer It could be that the server just isn't working for some reason, but we need to investigate in #54726

is there need to update asp.net as well?

@wfurt ASP.NET Core tests will need to be updated
https://github.com/dotnet/aspnetcore/blob/9da42b9fab4c61fe46627ac0c6877905ec845d5a/src/Servers/Kestrel/Transport.Quic/test/QuicTestHelpers.cs#L28 (cc @JamesNK)
But QuicTransportOptions does not seem to have any default value https://github.com/dotnet/aspnetcore/blob/8b30d862de6c9146f466061d51aa3f1414ee2337/src/Servers/Kestrel/Transport.Quic/src/QuicTransportOptions.cs In stress tests I specified ALPN manually for Kestrel https://github.com/dotnet/runtime/pull/56215/files#diff-73d3348ab4b049ae3561a8faf2c2ea98d1a379e035ecb65ccf5f21801b41a07fR130 And as I don't see any ALPN_NEG_FAILURE there and success rate is same as in main, I guess that's ok

I don't think we need to hold back for the test @CarnaViire. It would be nice. I see two possible strategies. QuicConnection has NegotiatedApplicationProtocol. And the handshake happens early on. So it seems like if you create QuicListener and do HttpRequest to it you should know - even if everything else fails. Alternatively we could update Loopback server and/or get access to it via some reflection.

is there need to update asp.net as well?

We'll update our configurable ALPN to h3. The property will probably be removed for RC1.