Improve side-by-side configuration of HTTP/1.1 and HTTP/2 endpoints

[JamesNK]

Is there an existing issue for this?

• I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.

ASP.NET Core supports simple configuration of endpoints using environment variables, such as ASPNETCORE_HTTP_PORTS, ASPNETCORE_HTTPS_PORTS, ASPNETCORE_URLS.

However, if an app needs to support HTTP/1.1 and HTTP/2 side-by-side and without TLS, then endpoints need to be manually configured:

• https://github.com/bradygaster/dotnet-cloud-native-build-2023/blob/06670816357cf816a88741daf7d73c6a4487122b/ContosoOnline/Products/appsettings.json#L10-L18
• https://github.com/bradygaster/dotnet-cloud-native-build-2023/blob/06670816357cf816a88741daf7d73c6a4487122b/docker-compose.yml#L72-L74

Configuring endpoints manually is a wall of complexity that devs hit once they have this requirement. We should make this simple scenario simple to configure.

Require two ports is common in cloud-native apps:

• Apps don't use TLS to communicate because they're inside a private network, and having TLS certs everywhere is annoying. Therefore they can't use TLS+ALPN for protocol negotiation.
• Apps need HTTP/2 for gRPC and HTTP/1.1 for apps that don't support prenegotiated HTTP/2. For example, k8s health checks and Prometheus metrics scraping.

Describe the solution you'd like

A new environment variable for explicitly configuring HTTP/2 alongside by HTTP/1.1.

ASPNETCORE_HTTP_PORT=80
ASPNETCORE_HTTP2_PORT=81

ASPNETCORE_HTTP2_PORT port wouldn't use TLS. An alternative name is ASPNETCORE_H2C_PORT (HTTP/2 cleartext), but H2C isn't a commonly used term by devs.

We need to figure out how ASPNETCORE_HTTP2_PORT (and ASPNETCORE_HTTP_PORT) interacts with endpoint defaults.

If the endpoint default version is HTTP/1.1 then ASPNETCORE_HTTP2_PORT should stay HTTP/2. But what about TLS?

Additional context

No response

[JamesNK]

cc @davidfowl @bradygaster

[halter73]

I prefer ASPNETCORE_H2C_PORT. I agree that H2C is less commonly understood than HTTP2, but I don't think HTTP2 conveys the lack of TLS the way H2C does. I'd also be okay with ASPNETCORE_HTTP2_CLEARTEXT_PORT

[davidfowl]

For comparison:

• https://stackoverflow.com/questions/34108188/how-to-enable-h2c-in-nginx
• https://stackoverflow.com/questions/54470016/using-haproxy-to-proxy-h2c-requests
• Add http/2 cleartext server (h2c) support caddyserver/caddy#3227

[amcasey]

I found "H2C" a little hard to web search.

Are the proposed names intentionally singular? The existing names seem to be plural: ASPNETCORE_HTTP_PORTS

[amcasey]

Is this the sort of public surface area change we'd do an API review for or are those just for code? cc @halter73

[davidfowl]

I don't think this requires an API review.

[JamesNK]

Are the proposed names intentionally singular? The existing names seem to be plural: ASPNETCORE_HTTP_PORTS

It should be consistent. Are the existing names pluralized? I found both when searching. Where is the code that reads the existing env vars?

Is this the sort of public surface area change we'd do an API review for or are those just for code? cc @halter73

IMO yes. Configuration designed for general public use - env vars, JSON, msbuild project settings, etc - is part of the public API.

[davidfowl]

I wouldn't reduce everything developer facing to be "public API", API review is for a specific reason and it's fine to go through it for other reasons, but this isn't an API.

[JamesNK]

I don't want to debate the definition of API. Agree to disagree 😋

Either way, the things considered in API review - naming, consistency, avoiding breaking changes, designing with future-proofing in mind, etc - should be considered with configuration.

[davidfowl]

Just FYI, this didn't go to API review (#43135). Here's the PR #44194.

Trying to cram everything in there because a group of people review things isn't the answer.

[amcasey]

Are the proposed names intentionally singular? The existing names seem to be plural: ASPNETCORE_HTTP_PORTS

It should be consistent. Are the existing names pluralized? I found both when searching. Where is the code that reads the existing env vars?

I think the existing names are here: https://github.com/dotnet/aspnetcore/blob/main/src/Hosting/Abstractions/src/WebHostDefaults.cs