Reconsider enabling HTTP/3 by default in .NET 8

[adityamandaleeka]

We've had HTTP/3 enabled by default in Kestrel since .NET 8 Preview 1. As we are about to wrap up .NET 8 we need to decide whether to ship with that left as-is, or go back to having HTTP/3 support being opt-in.

Reasons to reconsider the default

• 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.

• 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.

Options

1. Do nothing; HTTP/3 will be enabled by default in .NET 8.
   • Developers on Windows will get the above Defender pop-ups the first time they launch a specific app (subsequent launches of the same application will not trigger the pop-up unless it is renamed).
2. Disable HTTP/3 by default only in Development mode (leave it enabled by default in other modes). Developers who want it will be able to easily enable it.
   • The downside of this is that things will run differently by default during development than how they run in production.
3. Disable HTTP/3 by default in all modes. Developers who want it will be able to easily enable it.
   • Keep the status quo in .NET 8. People who do nothing to opt into HTTP/3 will continue to get HTTP/1 and /2 by default.

[adityamandaleeka]

I've chatted with a few folks on the team and we're currently leaning towards 3. 2 seemed like a good compromise, but we worry about the consequences of having the default protocol be different between development and production.

[adityamandaleeka]

cc @amcasey @DamianEdwards @JamesNK

[davidfowl]

Agree, lets turn it off by default 😄 .

[DamianEdwards]

Agreed, disable it by default.

[danmoseley]

@richlander you were just now asking about this but with container size motivation.

[mitchdenny]

My 2c is that I think we have some level of obligation as the .NET web app dev platfrom to advocate for protocol advancement. That doesn't necessarily mean we have to enable HTTP/3 this time but I do think we need to work with the Defender team so that Windows better handles HTTP/3 endpoints for development and with Chrome/Edge to make sure that the developer experience for inner loop development on HTTP/3 is improved moving forward.

[adityamandaleeka]

Absolutely @mitchdenny. I've kicked off that conversation with the Windows team and we should continue to advocate for the best experience possible here. I'm hopeful that in a future release we'll be able to go HTTP/3 by default without the drawbacks I mentioned above.

[richlander]

Container tracking issue: dotnet/dotnet-docker#4385 (comment)

Needless to say, if HTTP/3 is disabled by default, we won't seek to add it to any container images. We should also have a discussion with the the msquic team. The size of libmsquic is prohibitive.

[adityamandaleeka]

I've opened a PR for this in the RC1 branch since it's not clear to me whether we want to make this change in main for now. I'm open to feedback/thoughts about that.

[adityamandaleeka]

Note: we'll need to update docs as well when this change goes in.