[release/7.0] Fix HTTP/3 and HTTTP/2 header decoder buffer allocation

[ManickaP]

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.

• In 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.

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.

[ghost]

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

Issue Details

---

Backports #78862

Customer impact

In 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.

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 case of 4KB+ sized headers data buffers.

Author:	ManickaP
Assignees:	ManickaP
Labels:	area-System.Net.Http
Milestone:	-

[ManickaP]

Failures are unrelated: #84394 and #85304

[karelz]

Approved by Tactics (@SteveMCarroll) on 4/27 via email. Marking as servicing-approved.

[MihaZupan]

Should this be rebased against release/7.0-staging?

[carlossanlop]

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.

[ManickaP]

Closed in favor of #85977

[ManickaP]

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.

• In 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.

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.

[ghost]

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

Issue Details

---

Backports #78862

Customer impact

In 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.

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 case of 4KB+ sized headers data buffers.

Author:	ManickaP
Assignees:	ManickaP
Labels:	area-System.Net.Http
Milestone:	-

[ManickaP]

Failures are unrelated: #84394 and #85304

[karelz]

Approved by Tactics (@SteveMCarroll) on 4/27 via email. Marking as servicing-approved.

[MihaZupan]

Should this be rebased against release/7.0-staging?

[carlossanlop]

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.

[ManickaP]

Closed in favor of #85977

[ManickaP]

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.

• In 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.

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.

[ghost]

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

Issue Details

---

Backports #78862

Customer impact

In 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.

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 case of 4KB+ sized headers data buffers.

Author:	ManickaP
Assignees:	ManickaP
Labels:	area-System.Net.Http
Milestone:	-

[ManickaP]

Failures are unrelated: #84394 and #85304

[karelz]

Approved by Tactics (@SteveMCarroll) on 4/27 via email. Marking as servicing-approved.

[MihaZupan]

Should this be rebased against release/7.0-staging?

[carlossanlop]

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.

[ManickaP]

Closed in favor of #85977

[ManickaP]

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.

• In 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.

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.

[ghost]

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

Issue Details

---

Backports #78862

Customer impact

In 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.

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 case of 4KB+ sized headers data buffers.

Author:	ManickaP
Assignees:	ManickaP
Labels:	area-System.Net.Http
Milestone:	-

[ManickaP]

Failures are unrelated: #84394 and #85304

[karelz]

Approved by Tactics (@SteveMCarroll) on 4/27 via email. Marking as servicing-approved.

[MihaZupan]

Should this be rebased against release/7.0-staging?

[carlossanlop]

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.

[ManickaP]

Closed in favor of #85977

[ManickaP]

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.

• In 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.

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.

[ghost]

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

Issue Details

---

Backports #78862

Customer impact

In 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.

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 case of 4KB+ sized headers data buffers.

Author:	ManickaP
Assignees:	ManickaP
Labels:	area-System.Net.Http
Milestone:	-

[ManickaP]

Failures are unrelated: #84394 and #85304

[karelz]

Approved by Tactics (@SteveMCarroll) on 4/27 via email. Marking as servicing-approved.

[MihaZupan]

Should this be rebased against release/7.0-staging?

[carlossanlop]

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.

[ManickaP]

Closed in favor of #85977

[ManickaP]

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.

• In 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.

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.

[ghost]

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

Issue Details

---

Backports #78862

Customer impact

In 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.

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 case of 4KB+ sized headers data buffers.

Author:	ManickaP
Assignees:	ManickaP
Labels:	area-System.Net.Http
Milestone:	-

[ManickaP]

Failures are unrelated: #84394 and #85304

[karelz]

Approved by Tactics (@SteveMCarroll) on 4/27 via email. Marking as servicing-approved.

[MihaZupan]

Should this be rebased against release/7.0-staging?

[carlossanlop]

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.

[ManickaP]

Closed in favor of #85977

[ManickaP]

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.

• In 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.

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.

[ghost]

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

Issue Details

---

Backports #78862

Customer impact

In 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.

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 case of 4KB+ sized headers data buffers.

Author:	ManickaP
Assignees:	ManickaP
Labels:	area-System.Net.Http
Milestone:	-

[ManickaP]

Failures are unrelated: #84394 and #85304

[karelz]

Approved by Tactics (@SteveMCarroll) on 4/27 via email. Marking as servicing-approved.

[MihaZupan]

Should this be rebased against release/7.0-staging?

[carlossanlop]

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.

[ManickaP]

Closed in favor of #85977

[ManickaP]

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.

• In 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.

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.

[ghost]

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

Issue Details

---

Backports #78862

Customer impact

In 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.

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 case of 4KB+ sized headers data buffers.

Author:	ManickaP
Assignees:	ManickaP
Labels:	area-System.Net.Http
Milestone:	-

[ManickaP]

Failures are unrelated: #84394 and #85304

[karelz]

Approved by Tactics (@SteveMCarroll) on 4/27 via email. Marking as servicing-approved.

[MihaZupan]

Should this be rebased against release/7.0-staging?

[carlossanlop]

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.

[ManickaP]

Closed in favor of #85977