-
Notifications
You must be signed in to change notification settings - Fork 10.3k
Introduce trim-friendly APIs for controlling HTTPS Configuration support #47567
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Labels
api-approved
API was approved in API review, it can be implemented
area-networking
Includes servers, yarp, json patch, bedrock, websockets, http client factory, and http abstractions
Comments
Thank you for submitting this for API review. This will be reviewed by @dotnet/aspnet-api-review at the next meeting of the ASP.NET Core API Review group. Please ensure you take a look at the API review process documentation and ensure that:
|
PR: #47454 |
API Review notes:
API Approved! namespace Microsoft.AspNetCore.Hosting;
public static class WebHostBuilderKestrelExtensions
{
+ public static IWebHostBuilder UseKestrelHttpsConfiguration(this IWebHostBuilder hostBuilder);
+ public static IWebHostBuilder UseKestrelCore(this IWebHostBuilder hostBuilder);
} |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Labels
api-approved
API was approved in API review, it can be implemented
area-networking
Includes servers, yarp, json patch, bedrock, websockets, http client factory, and http abstractions
Background and Motivation
Not being able to trim HTTPS and QUIC support from apps that don't use them causes a very large size increase (~1MB on Windows and ~4MB on Linux). To be able to prove to the trim analyzer that they're not used, we need new code paths that statically do or do not reference the code we want to trim.
Context: #46681.
Proposed API
Please provide the specific public API signature diff that you are proposing. For example:
Note that the corresponding method for opting in to quic support already exists.
Usage Examples
Alternative Designs
Another approach would be to disable more things to make the behavior clearer.
For example, we could disable all HTTPS functionality and call this API
UseHttps
(or similar).We decided against doing this since our goal was not to provide guard rails but to improve trimming.
Instead, we make needing to call
UseHttpsConfiguration
as rare as possible (by calling it ourselves, when possible).Risks
The phrase "https configuration" has no intuitive meaning and the comments barely clarify.
This was by-design, since few users should need to call it and they should be prompted to do so by specialized error messages.
There is a risk that, not understanding its purpose, people will call it "just in case", hurting trimming perf.
The "core" in "UseKestrelCore" isn't related to either .NET Core or ASP.NET Core, which could cause some confusion.
The text was updated successfully, but these errors were encountered: