Uh oh!
There was an error while loading. Please reload this page.
[release/7.0] Respect SETTINGS_MAX_HEADER_LIST_SIZE on HTTP/2 and HTTP/3 - #79994
Conversation
ghost
commented
Dec 27, 2022
Tagging subscribers to this area: @dotnet/ncl Issue DetailsBackport of #79281 to release/7.0 /cc @MihaZupan Customer ImpactTestingRiskIMPORTANT: Is this backport for a servicing release? If so and this change touches code that ships in a NuGet package, please make certain that you have added any necessary package authoring and gotten it explicitly reviewed.
|
MihaZupan
commented
Jan 3, 2023
Build failure is unrelated: #79859 |
Approved by @SteveMCarroll via email on Thu 2023/1/5 2:32 AM - adding Servicing-approved label.
|
carlossanlop
commented
Jan 5, 2023
Approved by Tactics (7.0.3). |
Backport of #79281 to release/7.0
Fixes#78193
/cc @MihaZupan
Customer Impact
Without this change, users of HttpClient may randomly hit exceptions informing them that the server closed the connection. This is difficult to debug as nothing points you at the request headers being the culprit, and impacts reliability as unrelated requests may fail at the same time due to connection multiplexing.
With HTTP/2 and HTTP/3 the server has the option to advertise the maximum length of headers it is willing to receive.
This change respects that limit and fails offending requests before they make it onto the wire, improving the overall reliability of HttpClient while also providing a useful exception message to the user.
Testing
Added targeted CI tests.
The new behavior was validated with a test app running against Kestrel (both HTTP/2 and HTTP/3).
Risk
Low, this change enforces a limit that is specified by the server.
Any request that will fail with the new error was very likely already failing before.