HttpClient with HTTP/3 does not leverage the full QPACK static table

[ladeak]

Description

HttpClient with HTTP/3 does not leverage the full QPACK static table, https://www.rfc-editor.org/rfc/rfc9204.html#static-table

Reproduction Steps

var client = new HttpClient();
var request = new HttpRequestMessage(HttpMethod.Options, "https://somehttp3server") { Version = HttpVersion.Version30, VersionPolicy = HttpVersionPolicy.RequestVersionExact };
request.Headers.Add("access-control-request-method", "get");
request.Headers.Add("origin", "https://localhost");
var response = await client.SendAsync(request, HttpCompletionOption.ResponseHeadersRead);

Expected behavior

Both origin and access-control-request-method headers are encoded by their static table index from the QPACK RFC.

Actual behavior

Only the origin field name is encoded.
For access-control-request-method QPACK could use value 81 from the static table, as both the header name and value matches, however everything is encoded as string literals, that 'inflate' the size of the required frame size.

Regression?

No.

Known Workarounds

No known workarounds

Configuration

.NET 10, windows 11, x64;

Other information

No response

[dotnet-policy-service]

Tagging subscribers to this area: @karelz, @dotnet/ncl
See info in area-owners.md if you want to be subscribed.

[MihaZupan]

This is very similar to #60774 and #60935.
Figuring out whether header values map to a static entry costs CPU, and it hasn't so far been proven to be beneficial overall given the generally negligible impact on the amount of bandwidth that could be saved.

[ladeak]

Yes the linked issues look like the HTTP/2 counterparts. I agree on the additional CPU cost, but the static table entry has 98 entries. Not sure how much is already handled by HttpClient. Also not sure about the extra CPU cost of handling some of these entries, but there is also a gain, because both the header name and value can be precomputed (to the table index's encoded value), so no need for switching from UTF-16 encoding to Latin1 / UTF-8.

[MihaZupan]

The number of cases from the Qpack static table that are beneficial for clients looks quite narrow (seems like Content-Encoding would be the main one), making it less likely that extra branches are worth it for all other requests/headers.

I think the more realistic option would be that we try special-casing the default headers collection on HttpClient and have a pre-encoded version of that, in the hopes that we can just copy that onto the wire for many requests later down the line. That goes for things like #60935 as well.
But overall I'm not convinced it's a meaningful difference worth chasing at this point.