Make Kestrel default to HTTP/1 and /2

[adityamandaleeka]

Make Kestrel default to HTTP/1 and /2

We've had HTTP/3 enabled by default in Kestrel since .NET 8 Preview 1. This change reverts that so we go back to having HTTP/1 and /2 be the default.

Users who want HTTP/3 enabled can still do so; support for it is unaffected since this is just a change in defaults.

Description

We've decided to keep the default protocols in .NET 8 the same as they were in .NET 7 (no HTTP/3 by default). The main reason for this is that there's some added friction in the developer experience for all users, and we don't believe most people are benefiting from HTTP/3 during development anyway.

On Windows, launching an ASP.NET Core app for the first time with HTTP/3 causes a Defender warning to appear, asking you to confirm if the app should be allowed to communicate on Domain/Private/Public networks. This is added friction that we didn't have before, and is especially annoying if you work with multiple apps (you'll get a pop up for each one).

We believe this occurs because of the way msquic (which .NET's QUIC support is built upon) has to create its listener. It has to grab a wildcard listener up front because of how it supports multiplexing multiple apps on the same UDP port.

In addition to the above friction, getting HTTP/3 actually working locally with a browser takes a few extra steps. Browsers don't allow self-signed certificates on HTTP/3, so there's some effort required to get the end-to-end working anyway, and having to explicitly enable HTTP/3 on the server side isn't a huge added cost.

When this goes in, we will update the .NET 8 docs as well.

Fixes #50131

Customer Impact

• Devs who want HTTP/3 will need to opt into it. This matches the behavior in .NET 7.
• Devs on Windows will no longer get a Defender warning the first time they launch a .NET 8 app. This matches the behavior in .NET 7.

Regression?

• Yes
• No

While this is a different default than in all the .NET 8 Previews so far, the default protocols are going to be set the same as they were in .NET 7 so I don't consider this a regression.

Risk

• High
• Medium
• Low

This change makes the default HTTP protocols match what we shipped in 7.0 and match what has been, in practice, what we believe most of our customers have been getting in 8.0 previews anyway due to the extra steps involved in getting HTTP/3 working end to end.

Verification

• Manual (required)
• Automated

Packaging changes reviewed?

• Yes
• No
• N/A

[amcasey]

LGTM, assuming the tests pass.

[ghost]

Hi @adityamandaleeka. Please make sure you've updated the PR description to use the Shiproom Template. Also, make sure this PR is not marked as a draft and is ready-to-merge.

To learn more about how to prepare a servicing PR click here.

[ghost]

Hi @adityamandaleeka. This PR was just approved to be included in the upcoming servicing release. Somebody from the @dotnet/aspnet-build team will get it merged when the branches are open. Until then, please make sure all the CI checks pass and the PR is reviewed.

[ghost]

@adityamandaleeka, this change will be considered for inclusion in the blog post for the release it'll ship in. Nice work!

Please ensure that the original comment in this thread contains a clear explanation of what the change does, why it's important (what problem does it solve?), and, if relevant, include things like code samples and/or performance numbers.

This content may not be exactly what goes into the blog post, but it will help the team putting together the announcement.

Thanks!

[JamesNK]

Docs need to be updated: dotnet/AspNetCore.Docs#30114