http2: fix write deadlock exposed by larger window sizes

[pimterry]

This completes the fix from #65079. That PR resolved one test flake (test-worker-terminate-http2-respond-with-file), and reduced the second (test-stream-pipeline-http2) but left an underlying issue there which is still causing flakes.

This took more work, as it's a bit complicated. The issue is a real bug which can result in deadlocks between two Node HTTP/2 peers, not a test issue. This was preexisting though very hard to hit, but is exposed in some cases recently by the new window size update (#64623).

This PR fixes this by dropping a security guard (no reading while writing) completely. I've put it in two commits: the first does the tiny fix to drop the guard & tests it, the second removes various code which is now unreachable without the guard.

Dropping this guard needs careful review, but I think that dropping this guard is safe due to the various other mechanisms in place. As long as we're happy that this is safe, it has a lot of upsides: it fixes the flake, resolves a real deadlock, simply deletes some code, and provides some performance boosts.

An example deadlock flow looks roughly like this:

• Both peers are reading & writing.
• Peers write enough to fill the remote peer's TCP receive buffers (only now easily reachable, due to the larger window sizes).
• While TCP receive buffers are full, both peers try to write at the same time.
• The security guard here blocks reading while writing, so both peers stop reading.
• The buffers are all full, so TCP backpressure stops the writes completing - they wait for space.
• Both peers wait for their writes to complete, which requires a read to empty the buffers, but neither is reading => 🔒

This PR fixes that deadlock, by removing the "no reading while writing" guard completely, in its two forms.

These were added as part of a larger set of many HTTP/2 DoS mitigations in 2019 by @addaleax in #29122, so this needs careful review please!

I do think it's safe though: the key thing it's protecting against (one peer forcing the other to buffer large amounts of outgoing data through manipulation of flow control & window updates) is covered by other existing mechanisms here (most notably maxSessionMemory). I can't find any attacks that depend on this guard alone. I've added an additional test which covers CVE-2019-9517 directly, and confirms that maxSessionMemory blocks the key attack scenario regardless.

Removing this guard has notable performance benefits. @mcollina previously looked at this same issue briefly with #63009 testing small focused tweaks on the same guard. AFAICT tweaks alone had minimal benefit, but the guard is still a real perf problem, because it blocks all reads on the whole H2 session while writing any frames anywhere. That means during e.g. a large read (server large upload/client large download), every sent window update to read more data from any stream pauses reading on all streams until the write completes.

Many different dimensions where removing this entirely should improve things, but I've included one example in the benchmark here: this saturates TLS bidirectional streaming, and with this change you get roughly 25% throughput boost. This is using default settings except it shrinks the stream window size back to the standard H2 default - without that you can't benchmark against previous versions, because they deadlock.

[nodejs-github-bot]

Review requested:

• @nodejs/http2
• @nodejs/net
• @nodejs/performance

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.15%. Comparing base (fd5b135) to head (a68ec45).
⚠️ Report is 131 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #65440 +/- ##
==========================================
+ Coverage 90.12% 90.15% +0.03% 
==========================================
Files 752 751 -1 Lines 252325 253473 +1148 Branches 47456 47740 +284 ==========================================
+ Hits 227407 228520 +1113 - Misses 16217 16221 +4 - Partials 8701 8732 +31 

Files with missing lines	Coverage Δ
src/node_http2.cc	81.75% <100.00%> (+0.03%)	⬆️
src/node_http2.h	92.22% <ø> (-0.05%)	⬇️

... and 107 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[mcollina]

lgtm

[pimterry]

The previous extra security test I added wasn't stable on MacOS, seemingly due to differences in buffer & batching delivery. It didn't fail the security assertions, it just never completed.

This new test is aiming to cover the relevant security behaviour and show it passes with and without this change. I've now rewritten the test completely, to focus directly on the important CVE (my understanding: HTTP/2 writes must correctly apply transport backpressure: they should not silently accept & buffer content when writes stall but the HTTP/2 window is wide open). This now uses a raw socket client and readable with specific config to tightly target this in a way that should behave identically across platforms (I hope 🤞).

Open to adding other security tests here if anybody thinks there's more specific constraints we should validate. I have done even more digging, and I still can't find any cases this guard protects against that other mitigations don't already cover. A review from @nodejs/security would be nice though, especially if anybody was involved in the original 2019 HTTP/2 tightening.

[trivikr]

Ci is failing on Windows

not ok 666 parallel/test-http2-stream-backpressure-unread-peer --- duration_ms: 186.00800 severity: fail exitcode: 1 stack: |- node:internal/assert/utils:146 throw error; ^ AssertionError [ERR_ASSERTION]: Expected values to be strictly equal: 32768 !== 81920 at Immediate.<anonymous> (c:\workspace\node-test-binary-windows-js-suites\node\test\parallel\test-http2-stream-backpressure-unread-peer.js:115:14) at Immediate._onImmediate (c:\workspace\node-test-binary-windows-js-suites\node\test\common\index.js:511:15) at process.processImmediate (node:internal/timers:574:21) { generatedMessage: true, code: 'ERR_ASSERTION', actual: 32768, expected: 81920, operator: 'strictEqual', diff: 'simple' } Node.js v27.0.0-pre ...

https://ci.nodejs.org/job/node-test-binary-windows-js-suites/42576/RUN_SUBSET=3,nodes=win10-COMPILED_BY-vs2022_clang/console

[pimterry]

Thanks @trivikr! The previous test assertions made assumptions that didn't hold on Windows. Now fixed by widening the accepted range to properly match the real goal instead of being too specific, hopefully CI will confirm.

I've also now got a passing stress test result (from the previous commit, but relevant tests and code haven't changed), showing this fixes the test-stream-pipeline-http2 flake on MacOS16-x64: https://ci.nodejs.org/job/node-stress-single-test/nodes=macos15-x64/840/console

Main job for the same test still pending but will hopefully flake a bunch to clearly back that up.

https://ci.nodejs.org/job/node-stress-single-test/nodes=macos15-x64/842/ has now failed - 21 times out of 1000 runs, so this is a nice clear flake fix.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/76511/

[nodejs-github-bot]

Landed in 37887a3

[pimterry]

This completes the fix from #65079. That PR resolved one test flake (test-worker-terminate-http2-respond-with-file), and reduced the second (test-stream-pipeline-http2) but left an underlying issue there which is still causing flakes.

This took more work, as it's a bit complicated. The issue is a real bug which can result in deadlocks between two Node HTTP/2 peers, not a test issue. This was preexisting though very hard to hit, but is exposed in some cases recently by the new window size update (#64623).

This PR fixes this by dropping a security guard (no reading while writing) completely. I've put it in two commits: the first does the tiny fix to drop the guard & tests it, the second removes various code which is now unreachable without the guard.

Dropping this guard needs careful review, but I think that dropping this guard is safe due to the various other mechanisms in place. As long as we're happy that this is safe, it has a lot of upsides: it fixes the flake, resolves a real deadlock, simply deletes some code, and provides some performance boosts.

An example deadlock flow looks roughly like this:

• Both peers are reading & writing.
• Peers write enough to fill the remote peer's TCP receive buffers (only now easily reachable, due to the larger window sizes).
• While TCP receive buffers are full, both peers try to write at the same time.
• The security guard here blocks reading while writing, so both peers stop reading.
• The buffers are all full, so TCP backpressure stops the writes completing - they wait for space.
• Both peers wait for their writes to complete, which requires a read to empty the buffers, but neither is reading => 🔒

This PR fixes that deadlock, by removing the "no reading while writing" guard completely, in its two forms.

These were added as part of a larger set of many HTTP/2 DoS mitigations in 2019 by @addaleax in #29122, so this needs careful review please!

I do think it's safe though: the key thing it's protecting against (one peer forcing the other to buffer large amounts of outgoing data through manipulation of flow control & window updates) is covered by other existing mechanisms here (most notably maxSessionMemory). I can't find any attacks that depend on this guard alone. I've added an additional test which covers CVE-2019-9517 directly, and confirms that maxSessionMemory blocks the key attack scenario regardless.

Removing this guard has notable performance benefits. @mcollina previously looked at this same issue briefly with #63009 testing small focused tweaks on the same guard. AFAICT tweaks alone had minimal benefit, but the guard is still a real perf problem, because it blocks all reads on the whole H2 session while writing any frames anywhere. That means during e.g. a large read (server large upload/client large download), every sent window update to read more data from any stream pauses reading on all streams until the write completes.

Many different dimensions where removing this entirely should improve things, but I've included one example in the benchmark here: this saturates TLS bidirectional streaming, and with this change you get roughly 25% throughput boost. This is using default settings except it shrinks the stream window size back to the standard H2 default - without that you can't benchmark against previous versions, because they deadlock.

[nodejs-github-bot]

Review requested:

• @nodejs/http2
• @nodejs/net
• @nodejs/performance

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.15%. Comparing base (fd5b135) to head (a68ec45).
⚠️ Report is 131 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #65440 +/- ##
==========================================
+ Coverage 90.12% 90.15% +0.03% 
==========================================
Files 752 751 -1 Lines 252325 253473 +1148 Branches 47456 47740 +284 ==========================================
+ Hits 227407 228520 +1113 - Misses 16217 16221 +4 - Partials 8701 8732 +31 

Files with missing lines	Coverage Δ
src/node_http2.cc	81.75% <100.00%> (+0.03%)	⬆️
src/node_http2.h	92.22% <ø> (-0.05%)	⬇️

... and 107 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[mcollina]

lgtm

[pimterry]

The previous extra security test I added wasn't stable on MacOS, seemingly due to differences in buffer & batching delivery. It didn't fail the security assertions, it just never completed.

This new test is aiming to cover the relevant security behaviour and show it passes with and without this change. I've now rewritten the test completely, to focus directly on the important CVE (my understanding: HTTP/2 writes must correctly apply transport backpressure: they should not silently accept & buffer content when writes stall but the HTTP/2 window is wide open). This now uses a raw socket client and readable with specific config to tightly target this in a way that should behave identically across platforms (I hope 🤞).

Open to adding other security tests here if anybody thinks there's more specific constraints we should validate. I have done even more digging, and I still can't find any cases this guard protects against that other mitigations don't already cover. A review from @nodejs/security would be nice though, especially if anybody was involved in the original 2019 HTTP/2 tightening.

[trivikr]

Ci is failing on Windows

not ok 666 parallel/test-http2-stream-backpressure-unread-peer --- duration_ms: 186.00800 severity: fail exitcode: 1 stack: |- node:internal/assert/utils:146 throw error; ^ AssertionError [ERR_ASSERTION]: Expected values to be strictly equal: 32768 !== 81920 at Immediate.<anonymous> (c:\workspace\node-test-binary-windows-js-suites\node\test\parallel\test-http2-stream-backpressure-unread-peer.js:115:14) at Immediate._onImmediate (c:\workspace\node-test-binary-windows-js-suites\node\test\common\index.js:511:15) at process.processImmediate (node:internal/timers:574:21) { generatedMessage: true, code: 'ERR_ASSERTION', actual: 32768, expected: 81920, operator: 'strictEqual', diff: 'simple' } Node.js v27.0.0-pre ...

https://ci.nodejs.org/job/node-test-binary-windows-js-suites/42576/RUN_SUBSET=3,nodes=win10-COMPILED_BY-vs2022_clang/console

[pimterry]

Thanks @trivikr! The previous test assertions made assumptions that didn't hold on Windows. Now fixed by widening the accepted range to properly match the real goal instead of being too specific, hopefully CI will confirm.

I've also now got a passing stress test result (from the previous commit, but relevant tests and code haven't changed), showing this fixes the test-stream-pipeline-http2 flake on MacOS16-x64: https://ci.nodejs.org/job/node-stress-single-test/nodes=macos15-x64/840/console

Main job for the same test still pending but will hopefully flake a bunch to clearly back that up.

https://ci.nodejs.org/job/node-stress-single-test/nodes=macos15-x64/842/ has now failed - 21 times out of 1000 runs, so this is a nice clear flake fix.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/76511/

[nodejs-github-bot]

Landed in 37887a3

[pimterry]

This completes the fix from #65079. That PR resolved one test flake (test-worker-terminate-http2-respond-with-file), and reduced the second (test-stream-pipeline-http2) but left an underlying issue there which is still causing flakes.

This took more work, as it's a bit complicated. The issue is a real bug which can result in deadlocks between two Node HTTP/2 peers, not a test issue. This was preexisting though very hard to hit, but is exposed in some cases recently by the new window size update (#64623).

This PR fixes this by dropping a security guard (no reading while writing) completely. I've put it in two commits: the first does the tiny fix to drop the guard & tests it, the second removes various code which is now unreachable without the guard.

Dropping this guard needs careful review, but I think that dropping this guard is safe due to the various other mechanisms in place. As long as we're happy that this is safe, it has a lot of upsides: it fixes the flake, resolves a real deadlock, simply deletes some code, and provides some performance boosts.

An example deadlock flow looks roughly like this:

• Both peers are reading & writing.
• Peers write enough to fill the remote peer's TCP receive buffers (only now easily reachable, due to the larger window sizes).
• While TCP receive buffers are full, both peers try to write at the same time.
• The security guard here blocks reading while writing, so both peers stop reading.
• The buffers are all full, so TCP backpressure stops the writes completing - they wait for space.
• Both peers wait for their writes to complete, which requires a read to empty the buffers, but neither is reading => 🔒

This PR fixes that deadlock, by removing the "no reading while writing" guard completely, in its two forms.

These were added as part of a larger set of many HTTP/2 DoS mitigations in 2019 by @addaleax in #29122, so this needs careful review please!

I do think it's safe though: the key thing it's protecting against (one peer forcing the other to buffer large amounts of outgoing data through manipulation of flow control & window updates) is covered by other existing mechanisms here (most notably maxSessionMemory). I can't find any attacks that depend on this guard alone. I've added an additional test which covers CVE-2019-9517 directly, and confirms that maxSessionMemory blocks the key attack scenario regardless.

Removing this guard has notable performance benefits. @mcollina previously looked at this same issue briefly with #63009 testing small focused tweaks on the same guard. AFAICT tweaks alone had minimal benefit, but the guard is still a real perf problem, because it blocks all reads on the whole H2 session while writing any frames anywhere. That means during e.g. a large read (server large upload/client large download), every sent window update to read more data from any stream pauses reading on all streams until the write completes.

Many different dimensions where removing this entirely should improve things, but I've included one example in the benchmark here: this saturates TLS bidirectional streaming, and with this change you get roughly 25% throughput boost. This is using default settings except it shrinks the stream window size back to the standard H2 default - without that you can't benchmark against previous versions, because they deadlock.

[nodejs-github-bot]

Review requested:

• @nodejs/http2
• @nodejs/net
• @nodejs/performance

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.15%. Comparing base (fd5b135) to head (a68ec45).
⚠️ Report is 131 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #65440 +/- ##
==========================================
+ Coverage 90.12% 90.15% +0.03% 
==========================================
Files 752 751 -1 Lines 252325 253473 +1148 Branches 47456 47740 +284 ==========================================
+ Hits 227407 228520 +1113 - Misses 16217 16221 +4 - Partials 8701 8732 +31 

Files with missing lines	Coverage Δ
src/node_http2.cc	81.75% <100.00%> (+0.03%)	⬆️
src/node_http2.h	92.22% <ø> (-0.05%)	⬇️

... and 107 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[mcollina]

lgtm

[pimterry]

The previous extra security test I added wasn't stable on MacOS, seemingly due to differences in buffer & batching delivery. It didn't fail the security assertions, it just never completed.

This new test is aiming to cover the relevant security behaviour and show it passes with and without this change. I've now rewritten the test completely, to focus directly on the important CVE (my understanding: HTTP/2 writes must correctly apply transport backpressure: they should not silently accept & buffer content when writes stall but the HTTP/2 window is wide open). This now uses a raw socket client and readable with specific config to tightly target this in a way that should behave identically across platforms (I hope 🤞).

Open to adding other security tests here if anybody thinks there's more specific constraints we should validate. I have done even more digging, and I still can't find any cases this guard protects against that other mitigations don't already cover. A review from @nodejs/security would be nice though, especially if anybody was involved in the original 2019 HTTP/2 tightening.

[trivikr]

Ci is failing on Windows

not ok 666 parallel/test-http2-stream-backpressure-unread-peer --- duration_ms: 186.00800 severity: fail exitcode: 1 stack: |- node:internal/assert/utils:146 throw error; ^ AssertionError [ERR_ASSERTION]: Expected values to be strictly equal: 32768 !== 81920 at Immediate.<anonymous> (c:\workspace\node-test-binary-windows-js-suites\node\test\parallel\test-http2-stream-backpressure-unread-peer.js:115:14) at Immediate._onImmediate (c:\workspace\node-test-binary-windows-js-suites\node\test\common\index.js:511:15) at process.processImmediate (node:internal/timers:574:21) { generatedMessage: true, code: 'ERR_ASSERTION', actual: 32768, expected: 81920, operator: 'strictEqual', diff: 'simple' } Node.js v27.0.0-pre ...

https://ci.nodejs.org/job/node-test-binary-windows-js-suites/42576/RUN_SUBSET=3,nodes=win10-COMPILED_BY-vs2022_clang/console

[pimterry]

Thanks @trivikr! The previous test assertions made assumptions that didn't hold on Windows. Now fixed by widening the accepted range to properly match the real goal instead of being too specific, hopefully CI will confirm.

I've also now got a passing stress test result (from the previous commit, but relevant tests and code haven't changed), showing this fixes the test-stream-pipeline-http2 flake on MacOS16-x64: https://ci.nodejs.org/job/node-stress-single-test/nodes=macos15-x64/840/console

Main job for the same test still pending but will hopefully flake a bunch to clearly back that up.

https://ci.nodejs.org/job/node-stress-single-test/nodes=macos15-x64/842/ has now failed - 21 times out of 1000 runs, so this is a nice clear flake fix.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/76511/

[nodejs-github-bot]

Landed in 37887a3

[pimterry]

This completes the fix from #65079. That PR resolved one test flake (test-worker-terminate-http2-respond-with-file), and reduced the second (test-stream-pipeline-http2) but left an underlying issue there which is still causing flakes.

This took more work, as it's a bit complicated. The issue is a real bug which can result in deadlocks between two Node HTTP/2 peers, not a test issue. This was preexisting though very hard to hit, but is exposed in some cases recently by the new window size update (#64623).

This PR fixes this by dropping a security guard (no reading while writing) completely. I've put it in two commits: the first does the tiny fix to drop the guard & tests it, the second removes various code which is now unreachable without the guard.

Dropping this guard needs careful review, but I think that dropping this guard is safe due to the various other mechanisms in place. As long as we're happy that this is safe, it has a lot of upsides: it fixes the flake, resolves a real deadlock, simply deletes some code, and provides some performance boosts.

An example deadlock flow looks roughly like this:

• Both peers are reading & writing.
• Peers write enough to fill the remote peer's TCP receive buffers (only now easily reachable, due to the larger window sizes).
• While TCP receive buffers are full, both peers try to write at the same time.
• The security guard here blocks reading while writing, so both peers stop reading.
• The buffers are all full, so TCP backpressure stops the writes completing - they wait for space.
• Both peers wait for their writes to complete, which requires a read to empty the buffers, but neither is reading => 🔒

This PR fixes that deadlock, by removing the "no reading while writing" guard completely, in its two forms.

These were added as part of a larger set of many HTTP/2 DoS mitigations in 2019 by @addaleax in #29122, so this needs careful review please!

I do think it's safe though: the key thing it's protecting against (one peer forcing the other to buffer large amounts of outgoing data through manipulation of flow control & window updates) is covered by other existing mechanisms here (most notably maxSessionMemory). I can't find any attacks that depend on this guard alone. I've added an additional test which covers CVE-2019-9517 directly, and confirms that maxSessionMemory blocks the key attack scenario regardless.

Removing this guard has notable performance benefits. @mcollina previously looked at this same issue briefly with #63009 testing small focused tweaks on the same guard. AFAICT tweaks alone had minimal benefit, but the guard is still a real perf problem, because it blocks all reads on the whole H2 session while writing any frames anywhere. That means during e.g. a large read (server large upload/client large download), every sent window update to read more data from any stream pauses reading on all streams until the write completes.

Many different dimensions where removing this entirely should improve things, but I've included one example in the benchmark here: this saturates TLS bidirectional streaming, and with this change you get roughly 25% throughput boost. This is using default settings except it shrinks the stream window size back to the standard H2 default - without that you can't benchmark against previous versions, because they deadlock.

[nodejs-github-bot]

Review requested:

• @nodejs/http2
• @nodejs/net
• @nodejs/performance

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.15%. Comparing base (fd5b135) to head (a68ec45).
⚠️ Report is 131 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #65440 +/- ##
==========================================
+ Coverage 90.12% 90.15% +0.03% 
==========================================
Files 752 751 -1 Lines 252325 253473 +1148 Branches 47456 47740 +284 ==========================================
+ Hits 227407 228520 +1113 - Misses 16217 16221 +4 - Partials 8701 8732 +31 

Files with missing lines	Coverage Δ
src/node_http2.cc	81.75% <100.00%> (+0.03%)	⬆️
src/node_http2.h	92.22% <ø> (-0.05%)	⬇️

... and 107 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[mcollina]

lgtm

[pimterry]

The previous extra security test I added wasn't stable on MacOS, seemingly due to differences in buffer & batching delivery. It didn't fail the security assertions, it just never completed.

This new test is aiming to cover the relevant security behaviour and show it passes with and without this change. I've now rewritten the test completely, to focus directly on the important CVE (my understanding: HTTP/2 writes must correctly apply transport backpressure: they should not silently accept & buffer content when writes stall but the HTTP/2 window is wide open). This now uses a raw socket client and readable with specific config to tightly target this in a way that should behave identically across platforms (I hope 🤞).

Open to adding other security tests here if anybody thinks there's more specific constraints we should validate. I have done even more digging, and I still can't find any cases this guard protects against that other mitigations don't already cover. A review from @nodejs/security would be nice though, especially if anybody was involved in the original 2019 HTTP/2 tightening.

[trivikr]

Ci is failing on Windows

not ok 666 parallel/test-http2-stream-backpressure-unread-peer --- duration_ms: 186.00800 severity: fail exitcode: 1 stack: |- node:internal/assert/utils:146 throw error; ^ AssertionError [ERR_ASSERTION]: Expected values to be strictly equal: 32768 !== 81920 at Immediate.<anonymous> (c:\workspace\node-test-binary-windows-js-suites\node\test\parallel\test-http2-stream-backpressure-unread-peer.js:115:14) at Immediate._onImmediate (c:\workspace\node-test-binary-windows-js-suites\node\test\common\index.js:511:15) at process.processImmediate (node:internal/timers:574:21) { generatedMessage: true, code: 'ERR_ASSERTION', actual: 32768, expected: 81920, operator: 'strictEqual', diff: 'simple' } Node.js v27.0.0-pre ...

https://ci.nodejs.org/job/node-test-binary-windows-js-suites/42576/RUN_SUBSET=3,nodes=win10-COMPILED_BY-vs2022_clang/console

[pimterry]

Thanks @trivikr! The previous test assertions made assumptions that didn't hold on Windows. Now fixed by widening the accepted range to properly match the real goal instead of being too specific, hopefully CI will confirm.

I've also now got a passing stress test result (from the previous commit, but relevant tests and code haven't changed), showing this fixes the test-stream-pipeline-http2 flake on MacOS16-x64: https://ci.nodejs.org/job/node-stress-single-test/nodes=macos15-x64/840/console

Main job for the same test still pending but will hopefully flake a bunch to clearly back that up.

https://ci.nodejs.org/job/node-stress-single-test/nodes=macos15-x64/842/ has now failed - 21 times out of 1000 runs, so this is a nice clear flake fix.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/76511/

[nodejs-github-bot]

Landed in 37887a3

[pimterry]

This completes the fix from #65079. That PR resolved one test flake (test-worker-terminate-http2-respond-with-file), and reduced the second (test-stream-pipeline-http2) but left an underlying issue there which is still causing flakes.

This took more work, as it's a bit complicated. The issue is a real bug which can result in deadlocks between two Node HTTP/2 peers, not a test issue. This was preexisting though very hard to hit, but is exposed in some cases recently by the new window size update (#64623).

This PR fixes this by dropping a security guard (no reading while writing) completely. I've put it in two commits: the first does the tiny fix to drop the guard & tests it, the second removes various code which is now unreachable without the guard.

Dropping this guard needs careful review, but I think that dropping this guard is safe due to the various other mechanisms in place. As long as we're happy that this is safe, it has a lot of upsides: it fixes the flake, resolves a real deadlock, simply deletes some code, and provides some performance boosts.

An example deadlock flow looks roughly like this:

• Both peers are reading & writing.
• Peers write enough to fill the remote peer's TCP receive buffers (only now easily reachable, due to the larger window sizes).
• While TCP receive buffers are full, both peers try to write at the same time.
• The security guard here blocks reading while writing, so both peers stop reading.
• The buffers are all full, so TCP backpressure stops the writes completing - they wait for space.
• Both peers wait for their writes to complete, which requires a read to empty the buffers, but neither is reading => 🔒

This PR fixes that deadlock, by removing the "no reading while writing" guard completely, in its two forms.

These were added as part of a larger set of many HTTP/2 DoS mitigations in 2019 by @addaleax in #29122, so this needs careful review please!

I do think it's safe though: the key thing it's protecting against (one peer forcing the other to buffer large amounts of outgoing data through manipulation of flow control & window updates) is covered by other existing mechanisms here (most notably maxSessionMemory). I can't find any attacks that depend on this guard alone. I've added an additional test which covers CVE-2019-9517 directly, and confirms that maxSessionMemory blocks the key attack scenario regardless.

Removing this guard has notable performance benefits. @mcollina previously looked at this same issue briefly with #63009 testing small focused tweaks on the same guard. AFAICT tweaks alone had minimal benefit, but the guard is still a real perf problem, because it blocks all reads on the whole H2 session while writing any frames anywhere. That means during e.g. a large read (server large upload/client large download), every sent window update to read more data from any stream pauses reading on all streams until the write completes.

Many different dimensions where removing this entirely should improve things, but I've included one example in the benchmark here: this saturates TLS bidirectional streaming, and with this change you get roughly 25% throughput boost. This is using default settings except it shrinks the stream window size back to the standard H2 default - without that you can't benchmark against previous versions, because they deadlock.

[nodejs-github-bot]

Review requested:

• @nodejs/http2
• @nodejs/net
• @nodejs/performance

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.15%. Comparing base (fd5b135) to head (a68ec45).
⚠️ Report is 131 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #65440 +/- ##
==========================================
+ Coverage 90.12% 90.15% +0.03% 
==========================================
Files 752 751 -1 Lines 252325 253473 +1148 Branches 47456 47740 +284 ==========================================
+ Hits 227407 228520 +1113 - Misses 16217 16221 +4 - Partials 8701 8732 +31 

Files with missing lines	Coverage Δ
src/node_http2.cc	81.75% <100.00%> (+0.03%)	⬆️
src/node_http2.h	92.22% <ø> (-0.05%)	⬇️

... and 107 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[mcollina]

lgtm

[pimterry]

The previous extra security test I added wasn't stable on MacOS, seemingly due to differences in buffer & batching delivery. It didn't fail the security assertions, it just never completed.

This new test is aiming to cover the relevant security behaviour and show it passes with and without this change. I've now rewritten the test completely, to focus directly on the important CVE (my understanding: HTTP/2 writes must correctly apply transport backpressure: they should not silently accept & buffer content when writes stall but the HTTP/2 window is wide open). This now uses a raw socket client and readable with specific config to tightly target this in a way that should behave identically across platforms (I hope 🤞).

Open to adding other security tests here if anybody thinks there's more specific constraints we should validate. I have done even more digging, and I still can't find any cases this guard protects against that other mitigations don't already cover. A review from @nodejs/security would be nice though, especially if anybody was involved in the original 2019 HTTP/2 tightening.

[trivikr]

Ci is failing on Windows

not ok 666 parallel/test-http2-stream-backpressure-unread-peer --- duration_ms: 186.00800 severity: fail exitcode: 1 stack: |- node:internal/assert/utils:146 throw error; ^ AssertionError [ERR_ASSERTION]: Expected values to be strictly equal: 32768 !== 81920 at Immediate.<anonymous> (c:\workspace\node-test-binary-windows-js-suites\node\test\parallel\test-http2-stream-backpressure-unread-peer.js:115:14) at Immediate._onImmediate (c:\workspace\node-test-binary-windows-js-suites\node\test\common\index.js:511:15) at process.processImmediate (node:internal/timers:574:21) { generatedMessage: true, code: 'ERR_ASSERTION', actual: 32768, expected: 81920, operator: 'strictEqual', diff: 'simple' } Node.js v27.0.0-pre ...

https://ci.nodejs.org/job/node-test-binary-windows-js-suites/42576/RUN_SUBSET=3,nodes=win10-COMPILED_BY-vs2022_clang/console

[pimterry]

Thanks @trivikr! The previous test assertions made assumptions that didn't hold on Windows. Now fixed by widening the accepted range to properly match the real goal instead of being too specific, hopefully CI will confirm.

I've also now got a passing stress test result (from the previous commit, but relevant tests and code haven't changed), showing this fixes the test-stream-pipeline-http2 flake on MacOS16-x64: https://ci.nodejs.org/job/node-stress-single-test/nodes=macos15-x64/840/console

Main job for the same test still pending but will hopefully flake a bunch to clearly back that up.

https://ci.nodejs.org/job/node-stress-single-test/nodes=macos15-x64/842/ has now failed - 21 times out of 1000 runs, so this is a nice clear flake fix.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/76511/

[nodejs-github-bot]

Landed in 37887a3

[pimterry]

This completes the fix from #65079. That PR resolved one test flake (test-worker-terminate-http2-respond-with-file), and reduced the second (test-stream-pipeline-http2) but left an underlying issue there which is still causing flakes.

This took more work, as it's a bit complicated. The issue is a real bug which can result in deadlocks between two Node HTTP/2 peers, not a test issue. This was preexisting though very hard to hit, but is exposed in some cases recently by the new window size update (#64623).

This PR fixes this by dropping a security guard (no reading while writing) completely. I've put it in two commits: the first does the tiny fix to drop the guard & tests it, the second removes various code which is now unreachable without the guard.

Dropping this guard needs careful review, but I think that dropping this guard is safe due to the various other mechanisms in place. As long as we're happy that this is safe, it has a lot of upsides: it fixes the flake, resolves a real deadlock, simply deletes some code, and provides some performance boosts.

An example deadlock flow looks roughly like this:

• Both peers are reading & writing.
• Peers write enough to fill the remote peer's TCP receive buffers (only now easily reachable, due to the larger window sizes).
• While TCP receive buffers are full, both peers try to write at the same time.
• The security guard here blocks reading while writing, so both peers stop reading.
• The buffers are all full, so TCP backpressure stops the writes completing - they wait for space.
• Both peers wait for their writes to complete, which requires a read to empty the buffers, but neither is reading => 🔒

This PR fixes that deadlock, by removing the "no reading while writing" guard completely, in its two forms.

These were added as part of a larger set of many HTTP/2 DoS mitigations in 2019 by @addaleax in #29122, so this needs careful review please!

I do think it's safe though: the key thing it's protecting against (one peer forcing the other to buffer large amounts of outgoing data through manipulation of flow control & window updates) is covered by other existing mechanisms here (most notably maxSessionMemory). I can't find any attacks that depend on this guard alone. I've added an additional test which covers CVE-2019-9517 directly, and confirms that maxSessionMemory blocks the key attack scenario regardless.

Removing this guard has notable performance benefits. @mcollina previously looked at this same issue briefly with #63009 testing small focused tweaks on the same guard. AFAICT tweaks alone had minimal benefit, but the guard is still a real perf problem, because it blocks all reads on the whole H2 session while writing any frames anywhere. That means during e.g. a large read (server large upload/client large download), every sent window update to read more data from any stream pauses reading on all streams until the write completes.

Many different dimensions where removing this entirely should improve things, but I've included one example in the benchmark here: this saturates TLS bidirectional streaming, and with this change you get roughly 25% throughput boost. This is using default settings except it shrinks the stream window size back to the standard H2 default - without that you can't benchmark against previous versions, because they deadlock.

[nodejs-github-bot]

Review requested:

• @nodejs/http2
• @nodejs/net
• @nodejs/performance

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.15%. Comparing base (fd5b135) to head (a68ec45).
⚠️ Report is 131 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #65440 +/- ##
==========================================
+ Coverage 90.12% 90.15% +0.03% 
==========================================
Files 752 751 -1 Lines 252325 253473 +1148 Branches 47456 47740 +284 ==========================================
+ Hits 227407 228520 +1113 - Misses 16217 16221 +4 - Partials 8701 8732 +31 

Files with missing lines	Coverage Δ
src/node_http2.cc	81.75% <100.00%> (+0.03%)	⬆️
src/node_http2.h	92.22% <ø> (-0.05%)	⬇️

... and 107 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[mcollina]

lgtm

[pimterry]

The previous extra security test I added wasn't stable on MacOS, seemingly due to differences in buffer & batching delivery. It didn't fail the security assertions, it just never completed.

This new test is aiming to cover the relevant security behaviour and show it passes with and without this change. I've now rewritten the test completely, to focus directly on the important CVE (my understanding: HTTP/2 writes must correctly apply transport backpressure: they should not silently accept & buffer content when writes stall but the HTTP/2 window is wide open). This now uses a raw socket client and readable with specific config to tightly target this in a way that should behave identically across platforms (I hope 🤞).

Open to adding other security tests here if anybody thinks there's more specific constraints we should validate. I have done even more digging, and I still can't find any cases this guard protects against that other mitigations don't already cover. A review from @nodejs/security would be nice though, especially if anybody was involved in the original 2019 HTTP/2 tightening.

[trivikr]

Ci is failing on Windows

not ok 666 parallel/test-http2-stream-backpressure-unread-peer --- duration_ms: 186.00800 severity: fail exitcode: 1 stack: |- node:internal/assert/utils:146 throw error; ^ AssertionError [ERR_ASSERTION]: Expected values to be strictly equal: 32768 !== 81920 at Immediate.<anonymous> (c:\workspace\node-test-binary-windows-js-suites\node\test\parallel\test-http2-stream-backpressure-unread-peer.js:115:14) at Immediate._onImmediate (c:\workspace\node-test-binary-windows-js-suites\node\test\common\index.js:511:15) at process.processImmediate (node:internal/timers:574:21) { generatedMessage: true, code: 'ERR_ASSERTION', actual: 32768, expected: 81920, operator: 'strictEqual', diff: 'simple' } Node.js v27.0.0-pre ...

https://ci.nodejs.org/job/node-test-binary-windows-js-suites/42576/RUN_SUBSET=3,nodes=win10-COMPILED_BY-vs2022_clang/console

[pimterry]

Thanks @trivikr! The previous test assertions made assumptions that didn't hold on Windows. Now fixed by widening the accepted range to properly match the real goal instead of being too specific, hopefully CI will confirm.

I've also now got a passing stress test result (from the previous commit, but relevant tests and code haven't changed), showing this fixes the test-stream-pipeline-http2 flake on MacOS16-x64: https://ci.nodejs.org/job/node-stress-single-test/nodes=macos15-x64/840/console

Main job for the same test still pending but will hopefully flake a bunch to clearly back that up.

https://ci.nodejs.org/job/node-stress-single-test/nodes=macos15-x64/842/ has now failed - 21 times out of 1000 runs, so this is a nice clear flake fix.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/76511/

[nodejs-github-bot]

Landed in 37887a3

[pimterry]

This completes the fix from #65079. That PR resolved one test flake (test-worker-terminate-http2-respond-with-file), and reduced the second (test-stream-pipeline-http2) but left an underlying issue there which is still causing flakes.

This took more work, as it's a bit complicated. The issue is a real bug which can result in deadlocks between two Node HTTP/2 peers, not a test issue. This was preexisting though very hard to hit, but is exposed in some cases recently by the new window size update (#64623).

This PR fixes this by dropping a security guard (no reading while writing) completely. I've put it in two commits: the first does the tiny fix to drop the guard & tests it, the second removes various code which is now unreachable without the guard.

Dropping this guard needs careful review, but I think that dropping this guard is safe due to the various other mechanisms in place. As long as we're happy that this is safe, it has a lot of upsides: it fixes the flake, resolves a real deadlock, simply deletes some code, and provides some performance boosts.

An example deadlock flow looks roughly like this:

• Both peers are reading & writing.
• Peers write enough to fill the remote peer's TCP receive buffers (only now easily reachable, due to the larger window sizes).
• While TCP receive buffers are full, both peers try to write at the same time.
• The security guard here blocks reading while writing, so both peers stop reading.
• The buffers are all full, so TCP backpressure stops the writes completing - they wait for space.
• Both peers wait for their writes to complete, which requires a read to empty the buffers, but neither is reading => 🔒

This PR fixes that deadlock, by removing the "no reading while writing" guard completely, in its two forms.

These were added as part of a larger set of many HTTP/2 DoS mitigations in 2019 by @addaleax in #29122, so this needs careful review please!

I do think it's safe though: the key thing it's protecting against (one peer forcing the other to buffer large amounts of outgoing data through manipulation of flow control & window updates) is covered by other existing mechanisms here (most notably maxSessionMemory). I can't find any attacks that depend on this guard alone. I've added an additional test which covers CVE-2019-9517 directly, and confirms that maxSessionMemory blocks the key attack scenario regardless.

Removing this guard has notable performance benefits. @mcollina previously looked at this same issue briefly with #63009 testing small focused tweaks on the same guard. AFAICT tweaks alone had minimal benefit, but the guard is still a real perf problem, because it blocks all reads on the whole H2 session while writing any frames anywhere. That means during e.g. a large read (server large upload/client large download), every sent window update to read more data from any stream pauses reading on all streams until the write completes.

Many different dimensions where removing this entirely should improve things, but I've included one example in the benchmark here: this saturates TLS bidirectional streaming, and with this change you get roughly 25% throughput boost. This is using default settings except it shrinks the stream window size back to the standard H2 default - without that you can't benchmark against previous versions, because they deadlock.

[nodejs-github-bot]

Review requested:

• @nodejs/http2
• @nodejs/net
• @nodejs/performance

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.15%. Comparing base (fd5b135) to head (a68ec45).
⚠️ Report is 131 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #65440 +/- ##
==========================================
+ Coverage 90.12% 90.15% +0.03% 
==========================================
Files 752 751 -1 Lines 252325 253473 +1148 Branches 47456 47740 +284 ==========================================
+ Hits 227407 228520 +1113 - Misses 16217 16221 +4 - Partials 8701 8732 +31 

Files with missing lines	Coverage Δ
src/node_http2.cc	81.75% <100.00%> (+0.03%)	⬆️
src/node_http2.h	92.22% <ø> (-0.05%)	⬇️

... and 107 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[mcollina]

lgtm

[pimterry]

The previous extra security test I added wasn't stable on MacOS, seemingly due to differences in buffer & batching delivery. It didn't fail the security assertions, it just never completed.

This new test is aiming to cover the relevant security behaviour and show it passes with and without this change. I've now rewritten the test completely, to focus directly on the important CVE (my understanding: HTTP/2 writes must correctly apply transport backpressure: they should not silently accept & buffer content when writes stall but the HTTP/2 window is wide open). This now uses a raw socket client and readable with specific config to tightly target this in a way that should behave identically across platforms (I hope 🤞).

Open to adding other security tests here if anybody thinks there's more specific constraints we should validate. I have done even more digging, and I still can't find any cases this guard protects against that other mitigations don't already cover. A review from @nodejs/security would be nice though, especially if anybody was involved in the original 2019 HTTP/2 tightening.

[trivikr]

Ci is failing on Windows

not ok 666 parallel/test-http2-stream-backpressure-unread-peer --- duration_ms: 186.00800 severity: fail exitcode: 1 stack: |- node:internal/assert/utils:146 throw error; ^ AssertionError [ERR_ASSERTION]: Expected values to be strictly equal: 32768 !== 81920 at Immediate.<anonymous> (c:\workspace\node-test-binary-windows-js-suites\node\test\parallel\test-http2-stream-backpressure-unread-peer.js:115:14) at Immediate._onImmediate (c:\workspace\node-test-binary-windows-js-suites\node\test\common\index.js:511:15) at process.processImmediate (node:internal/timers:574:21) { generatedMessage: true, code: 'ERR_ASSERTION', actual: 32768, expected: 81920, operator: 'strictEqual', diff: 'simple' } Node.js v27.0.0-pre ...

https://ci.nodejs.org/job/node-test-binary-windows-js-suites/42576/RUN_SUBSET=3,nodes=win10-COMPILED_BY-vs2022_clang/console

[pimterry]

Thanks @trivikr! The previous test assertions made assumptions that didn't hold on Windows. Now fixed by widening the accepted range to properly match the real goal instead of being too specific, hopefully CI will confirm.

I've also now got a passing stress test result (from the previous commit, but relevant tests and code haven't changed), showing this fixes the test-stream-pipeline-http2 flake on MacOS16-x64: https://ci.nodejs.org/job/node-stress-single-test/nodes=macos15-x64/840/console

Main job for the same test still pending but will hopefully flake a bunch to clearly back that up.

https://ci.nodejs.org/job/node-stress-single-test/nodes=macos15-x64/842/ has now failed - 21 times out of 1000 runs, so this is a nice clear flake fix.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/76511/

[nodejs-github-bot]

Landed in 37887a3

[pimterry]

This completes the fix from #65079. That PR resolved one test flake (test-worker-terminate-http2-respond-with-file), and reduced the second (test-stream-pipeline-http2) but left an underlying issue there which is still causing flakes.

This took more work, as it's a bit complicated. The issue is a real bug which can result in deadlocks between two Node HTTP/2 peers, not a test issue. This was preexisting though very hard to hit, but is exposed in some cases recently by the new window size update (#64623).

This PR fixes this by dropping a security guard (no reading while writing) completely. I've put it in two commits: the first does the tiny fix to drop the guard & tests it, the second removes various code which is now unreachable without the guard.

Dropping this guard needs careful review, but I think that dropping this guard is safe due to the various other mechanisms in place. As long as we're happy that this is safe, it has a lot of upsides: it fixes the flake, resolves a real deadlock, simply deletes some code, and provides some performance boosts.

An example deadlock flow looks roughly like this:

• Both peers are reading & writing.
• Peers write enough to fill the remote peer's TCP receive buffers (only now easily reachable, due to the larger window sizes).
• While TCP receive buffers are full, both peers try to write at the same time.
• The security guard here blocks reading while writing, so both peers stop reading.
• The buffers are all full, so TCP backpressure stops the writes completing - they wait for space.
• Both peers wait for their writes to complete, which requires a read to empty the buffers, but neither is reading => 🔒

This PR fixes that deadlock, by removing the "no reading while writing" guard completely, in its two forms.

These were added as part of a larger set of many HTTP/2 DoS mitigations in 2019 by @addaleax in #29122, so this needs careful review please!

I do think it's safe though: the key thing it's protecting against (one peer forcing the other to buffer large amounts of outgoing data through manipulation of flow control & window updates) is covered by other existing mechanisms here (most notably maxSessionMemory). I can't find any attacks that depend on this guard alone. I've added an additional test which covers CVE-2019-9517 directly, and confirms that maxSessionMemory blocks the key attack scenario regardless.

Removing this guard has notable performance benefits. @mcollina previously looked at this same issue briefly with #63009 testing small focused tweaks on the same guard. AFAICT tweaks alone had minimal benefit, but the guard is still a real perf problem, because it blocks all reads on the whole H2 session while writing any frames anywhere. That means during e.g. a large read (server large upload/client large download), every sent window update to read more data from any stream pauses reading on all streams until the write completes.

Many different dimensions where removing this entirely should improve things, but I've included one example in the benchmark here: this saturates TLS bidirectional streaming, and with this change you get roughly 25% throughput boost. This is using default settings except it shrinks the stream window size back to the standard H2 default - without that you can't benchmark against previous versions, because they deadlock.

[nodejs-github-bot]

Review requested:

• @nodejs/http2
• @nodejs/net
• @nodejs/performance

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 90.15%. Comparing base (fd5b135) to head (a68ec45).
⚠️ Report is 131 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #65440 +/- ##
==========================================
+ Coverage 90.12% 90.15% +0.03% 
==========================================
Files 752 751 -1 Lines 252325 253473 +1148 Branches 47456 47740 +284 ==========================================
+ Hits 227407 228520 +1113 - Misses 16217 16221 +4 - Partials 8701 8732 +31 

Files with missing lines	Coverage Δ
src/node_http2.cc	81.75% <100.00%> (+0.03%)	⬆️
src/node_http2.h	92.22% <ø> (-0.05%)	⬇️

... and 107 files with indirect coverage changes

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
• 📦 JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.

[mcollina]

lgtm

[pimterry]

The previous extra security test I added wasn't stable on MacOS, seemingly due to differences in buffer & batching delivery. It didn't fail the security assertions, it just never completed.

This new test is aiming to cover the relevant security behaviour and show it passes with and without this change. I've now rewritten the test completely, to focus directly on the important CVE (my understanding: HTTP/2 writes must correctly apply transport backpressure: they should not silently accept & buffer content when writes stall but the HTTP/2 window is wide open). This now uses a raw socket client and readable with specific config to tightly target this in a way that should behave identically across platforms (I hope 🤞).

Open to adding other security tests here if anybody thinks there's more specific constraints we should validate. I have done even more digging, and I still can't find any cases this guard protects against that other mitigations don't already cover. A review from @nodejs/security would be nice though, especially if anybody was involved in the original 2019 HTTP/2 tightening.

[trivikr]

Ci is failing on Windows

not ok 666 parallel/test-http2-stream-backpressure-unread-peer --- duration_ms: 186.00800 severity: fail exitcode: 1 stack: |- node:internal/assert/utils:146 throw error; ^ AssertionError [ERR_ASSERTION]: Expected values to be strictly equal: 32768 !== 81920 at Immediate.<anonymous> (c:\workspace\node-test-binary-windows-js-suites\node\test\parallel\test-http2-stream-backpressure-unread-peer.js:115:14) at Immediate._onImmediate (c:\workspace\node-test-binary-windows-js-suites\node\test\common\index.js:511:15) at process.processImmediate (node:internal/timers:574:21) { generatedMessage: true, code: 'ERR_ASSERTION', actual: 32768, expected: 81920, operator: 'strictEqual', diff: 'simple' } Node.js v27.0.0-pre ...

https://ci.nodejs.org/job/node-test-binary-windows-js-suites/42576/RUN_SUBSET=3,nodes=win10-COMPILED_BY-vs2022_clang/console

[pimterry]

Thanks @trivikr! The previous test assertions made assumptions that didn't hold on Windows. Now fixed by widening the accepted range to properly match the real goal instead of being too specific, hopefully CI will confirm.

I've also now got a passing stress test result (from the previous commit, but relevant tests and code haven't changed), showing this fixes the test-stream-pipeline-http2 flake on MacOS16-x64: https://ci.nodejs.org/job/node-stress-single-test/nodes=macos15-x64/840/console

Main job for the same test still pending but will hopefully flake a bunch to clearly back that up.

https://ci.nodejs.org/job/node-stress-single-test/nodes=macos15-x64/842/ has now failed - 21 times out of 1000 runs, so this is a nice clear flake fix.

[nodejs-github-bot]

CI: https://ci.nodejs.org/job/node-test-pull-request/76511/

[nodejs-github-bot]

Landed in 37887a3