Make TLS & QUIC Pay-for-Play (Redux) by amcasey · Pull Request #47454 · dotnet/aspnetcore (original) (raw)
Based on the feedback on #47209, I've prepared this substantially different approach. Whereas #47209 focuses on providing a describable set of restrictions and guardrails to prevent their violation, this PR focuses on making a best effort to improve trimmed size while breaking as few scenarios as possible.
What's disabled when you create a slim builder? You'll find out at bind-time if you crossed the line and a helpful error message will tell you the one-liner (either IWebHostBuilder.UseHttpsConfiguration or IWebHostBuilder.UseQuic) to add to fix it. What does that mean, in practice? Kestrel won't call UseHttps on your behalf - in particular, setting your URL to https won't "just work" - and there won't be any QUIC transports.
Presently, IWebHostBuilder.UseQuic doesn't imply IWebHostBuilder.UseHttpsConfiguration, but it could if we're willing to slightly clutter the public API (i.e. with a marker service in Connection.Abstractions).
There are exactly two new DI services, both internal:
IHttpsConfigurationHelperis always present, but throws until it is explicitly enabled.IEnableris a declarative way to enableIHttpsConfigurationHelper(vs a method call). I suspect there's a better way to do this in DI, but I'm not familiar enough with the available APIs.
There are two new public APIs (plus overloads):
UseKestrelSlim(name TBD) doesn't callUseQuicorIHttpsConfigurationHelper.Enable.UseHttpsConfiguration(effectively) callsIHttpsConfiguration.Enable.
I have more validation to do, but the trimmed size is as in #47209 and the tests pass.