[release/7.0] Fix HTTP/3 and HTTTP/2 header decoder buffer allocation #85337
Conversation
* Add test for literal field without name reference * Fix header name buffer allocation * Add more tests * Unified QPackDecoderTest test files * Fix variable name * Fixed HPackDecoder and ported QPack tests * Feedback --------- Co-authored-by: ManickaP <mapichov@microsoft.com>
|
Tagging subscribers to this area: @dotnet/ncl Issue DetailsBackports #78862 Customer impactIn HPack cases (HTTP/2 scenarios), the issue is much less likely to be hit as it requires 4KB of headers. In QPack (HTTP/3), the header size required to hit this is much smaller and that's where this was caught by the original issue reporter. In either case, this is a reliability problem and requests/responses that should be accepted might end up in an exception. Moreover, this is a shared code with Kestrel so this affects server side as well. TestingAdded tests for the root cause and similar scenarios, increasing test coverage. All of those are ran in CI. RiskLow, as this affects only QPack (H/3 is still not as wide-spread as other HTTP versions) and HPack in case of 4KB+ sized headers data buffers.
|
|
Approved by Tactics (@SteveMCarroll) on 4/27 via email. Marking as servicing-approved. |
|
Should this be rebased against |
There was a problem hiding this comment.
Yes, please re-target your PR to release/7.0-staging. The release/7.0 branch does not receive product fixes directly anymore.
When you re-target, please confirm the code changes in your PR remained the same. I've seen many times that other unrelated changes are included unexpectedly due to the change in branches.
If you haven't retargeted a PR to another branch before, click on the Edit button (for when you change the PR title) and you'll see a dropdown that lets you select the destination branch.
Reminder that code-complete for the June Release is May 15th. Please make sure to get this PR merged before that date.
ghost
added
the
needs-author-action
|
Closed in favor of #85977 |
Fixes #78516
Backports #78862
Customer impact
Reliability problem in HTTP/2 and HTTP/3, where some requests/responses with large headers that should be accepted might end up throwing exception.
This is a shared code with Kestrel so this affects server side as well - expect follow up PR in ASP.NET.
Testing
Added tests for the root cause and similar scenarios, increasing test coverage. All of those are ran in CI.
Risk
Low, as this affects only QPack (H/3 is still not as wide-spread as other HTTP versions) and HPack in (rare) case of 4KB+ sized headers data buffers.