Make HttpProtocols configuration parsing consistent with SslProtocols

[Eagle3386]

[Edit]

Discussion Summary: it's really not intuitive how to specify multiple protocols if there isn't an existing enum member for the combination (e.g. Http1AndHttp2 exists, but Http2AndHttp3 doesn't). It turns out you can you comma-separation - "Http2, Http3", but that's hard to discover and quite different from how it looks in code (which uses |). SslProtocols appears to support an actual JSON list ([amcasey] I'm not 100% sure the meaning is equivalent), but it's not clear why the two would be inconsistent. We should think about how to make them both consistent and intuitive.

The actual code change will likely be quite simple (Help Wanted?), but we probably need to think through what we actually want here.

Also, it might be time to introduce "TlsProtocols", given how deprecated SSL is.

[Original]

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.

Currently, there are 2 enums to limit allowed HTTP protocols in Kestrel:

aspnetcore/src/Servers/Kestrel/Core/src/HttpProtocols.cs

Line 30 in c1b7624

Http1AndHttp2 = Http1 | Http2,

aspnetcore/src/Servers/Kestrel/Core/src/HttpProtocols.cs

Line 40 in c1b7624

Http1AndHttp2AndHttp3 = Http1 | Http2 | Http3

For those of us already on the gRPC "train", HTTP/2 is the lowest possible version for us.
But as soon as we're going for HTTP/3, we've got to set the latter, Http1AndHttp2AndHttp3, which feels rather strange.

Additionally, I happen to have a scenario where a non-gRPC app & its services are supposed to explicitly exclude clients without at least HTTP/2 support - which is rather cumbersome to achieve, given how easy it would be with an added Http2AndHttp3 value.

Describe the solution you'd like

I'd like to have said Http2AndHttp3 added to the HttpProtocols enum.

Additional context

None I can think of right now, but I'd happily provide such on request.

[amcasey]

I wouldn't say that enum is our finest work. I believe the point of the "And" members you mentioned was to function as "All" values at the times they were added. Giving a name to each combination of flags wasn't really a goal because it would quickly become unwieldy (even more than the enum already has).

Is there a reason you can't set HttpProtocols.Http2 | HttpProtocols.Http3?

[Eagle3386]

@amcasey I do understand that & while there's always room for improvement (and refactoring 😉), I simply didn't even try your suggestion as Visual Studio would tell you this:

But I tried it just now & it seems to work - at least, there's no warning or even error.
However, due to my app being Blazor WASM standalone & talking via gRPC with my BFF backend, explicitly enforcing HTTP/3-only on both ends seems to be partly ignored/overridden, because there are still HTTP/2 calls being executed.. 😅

[amcasey]

Ah, I had assumed you were configuring the protocols in code - are you actually doing it in JSON?

Regarding enforcement, AFAIK, that property only tells the server which protocols to listen for (though, as noted above, I don't actually know which setting you're changing). I think your (new?) question is how to force gRPC to use HTTP/3 between your frontend and your backend?

[Eagle3386]

Yes, on the Kestrel side of life, it's JSON-only. 😉
It all started mostly due to different certificate paths on our different environments, but now it's also due to convenience (compile once, configure anytime) - here's the base for any environment:

// … left out for brevity…
  "Kestrel": {
    "EndpointDefaults": {
      // TODO: Remove below after https://github.com/dotnet/aspnetcore/blob/main/src/Servers/Kestrel/Core/src/ListenOptions.cs#L19
      //       includes HTTP/3 to enable it by default.
      "Protocols": "Http2 | Http3", // gRPC ensures HTTP/2 as minimum by itself.
      "SslProtocols": [ "Tls12", "Tls13" ]
    }
  },
// … left out for brevity…

On the client side, it's simply

// … left out for brevity…
channel.DisposeHttpClient = true;
channel.HttpHandler       = new GrpcWebHandler(GrpcWebMode.GrpcWeb, new HttpClientHandler());
channel.HttpVersionPolicy = HttpVersionPolicy.RequestVersionOrHigher;
// … left out for brevity…

because additionally setting channel.HttpVersion = new(3, 0); changes pretty much nothing: especially HTTP OPTIONS requests are still done via HTTP/2 - which brings me to confirming your last question.

Yes, I'd love to see the possibility of enforcing HTTP/3. IMHO, if that breaks gRPC(-Web) in Blazor, Kestrel or ASP.NET in general, that shouldn't be prevented by an "enforced downgrade" to HTTP/2 as lowest HttpVersion & instead should throw exception when something inside ASP.NET/Blazor/Kestrel suddenly can't play along.

However, I'm willing to accept the current state regarding that, because I got the impression that this is on the roadmap for "to be fixed in .NET 9/10" & not "someday in 203x".. 😅😉

[amcasey]

I would guess that string is just running through Enum.Parse, so I'd be pretty surprised if it handled | correctly. Personally, I think I'd rather improve parsing support than add a complete set of enum members.

Is this what you're looking for in terms of limiting versions? grpc/grpc-dotnet#2514

Edit: I think this is the parsing code.

aspnetcore/src/Servers/Kestrel/Core/src/Internal/ConfigurationReader.cs

Line 176 in f14f99e

private static HttpProtocols? ParseProtocols(string? protocols)

[Eagle3386]

Ok, thought there might be some magic or at least dragons deep down below, making it "somehow" working.
Thanks for pointing it out! 👍🏻

I'm rather looking for reverting James' limitation as I'm both, in full control of client / services & deliberately aiming for explicit exclusion of older browsers/platforms from access.

[amcasey]

I'm rather looking for reverting James' limitation as I'm both, in full control of client / services & deliberately aiming for explicit exclusion of older browsers/platforms from access.

You'd have to ask @JamesNK about that.

[Eagle3386]

Well, I already did: grpc/grpc-dotnet#2546 (comment)

But the outcome suggested to me that Kestrel would benefit from an Http2AndHttp3 enum value - which in turn caused me to open this issue.. 😅

Besides, as he wrote in the other issue, explicitly setting HttpVersion to 3.0 isn't fully respected - there are still calls done with HTTP/2 (mostly HTTP OPTIONS prefetch requests as I understand it).

[amcasey]

@Eagle3386 I've just learned that you can use commas to separate enum values. Do you want to give that a shot and see if you can specify HTTP/2 and HTTP/3?