-
Notifications
You must be signed in to change notification settings - Fork 10.1k
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] Fix HTTP/2 header decoder buffer allocation #47950
Conversation
Hi @ManickaP. If this is not a tell-mode PR, please make sure to follow the instructions laid out in the servicing process document. |
Hi @ManickaP. Please make sure you've updated the PR description to use the Shiproom Template. Also, make sure this PR is not marked as a draft and is ready-to-merge. To learn more about how to prepare a servicing PR click here. |
Approved by Tactics (@SteveMCarroll) on 4/28 via email. Marking as Servicing-approved. |
Hi @ManickaP. This PR was just approved to be included in the upcoming servicing release. Somebody from the @dotnet/aspnet-build team will get it merged when the branches are open. Until then, please make sure all the CI checks pass and the PR is reviewed. |
Need changes I added to the code sync PR to fix warnings - #47793 |
/azp run |
Azure Pipelines successfully started running 2 pipeline(s). |
@ManickaP here's a PR to this branch in your fork to fix the CI failures: ManickaP#124 |
Fix HPack test warnings
Merged and the pipelines are running, thank you for the fix! |
Components-e2e failure is known & unrelated |
Manual backport of #47793
Backport of runtime PR in main dotnet/runtime#78862
Port of runtime 6.0 PR dotnet/runtime#85341
Fixes dotnet/runtime#78516
/cc @Tratcher @JamesNK
Fix HTTTP/2 header decoder buffer allocation
Description
We resize an internal buffer by an incorrect amount, and subsequent copies to that buffer will throw. The problem occurs in HPack since 5.0.
Customer Impact
Reliability problem in HTTP/2 (HPack), where some requests/responses with large headers (4KB+) that should be accepted might end up throwing exception.
This is a shared code with runtime so this affects both client and server - existing PR in runtime: dotnet/runtime#85341.
Regression?
Risk
Low, as this affects only (rare) case of 4KB+ headers data buffers in HTTP/2 (HPack).
Verification
Added tests for the root cause and similar scenarios, increasing test coverage. All of those are ran in CI.
Packaging changes reviewed?