-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
[release/6.0] Respect SETTINGS_MAX_HEADER_LIST_SIZE on HTTP/2 #79997
[release/6.0] Respect SETTINGS_MAX_HEADER_LIST_SIZE on HTTP/2 #79997
Conversation
Tagging subscribers to this area: @dotnet/ncl Issue DetailsBackport of #79281 to release/6.0 (only the HTTP/2 part as HTTP/3 is not supported on .NET 6) /cc @MihaZupan Customer ImpactTODO TestingTODO RiskTODO
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Approved by @SteveMCarroll via email on Thu 2023/1/5 2:32 AM - adding Servicing-approved label.
|
Approved by Tactics (6.0.14). |
Backport of #79281 to release/6.0 (only the HTTP/2 part as HTTP/3 is not supported on .NET 6)
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 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.
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.