fix(h2): honour maxResponseSize

[ondraulehla]

This relates to...

Nothing filed. I noticed it while reading the two client implementations side by side after #5638.

Rationale

maxResponseSize is documented on the HTTP/2 client's own page, docs/docs/api/H2CClient.md:

maxResponseSize {number} The maximum allowed response body size in bytes. Use -1 to disable. Default: -1.

It is declared in types/h2c-client.d.ts and validated in lib/dispatcher/client.js (an H2CClient with maxResponseSize: -5 throws InvalidArgumentError), then stored into client[kMaxResponseSize]. lib/dispatcher/client-h2.js never reads that symbol, so the value is validated and then ignored. onData() forwards every chunk to request.onResponseData(chunk) with no byte accounting.

Server sends 4 MiB, client asks for maxResponseSize: 1024:

	HTTP/1.1 Client	h2c H2CClient
before	UND_ERR_RES_EXCEEDED_MAX_SIZE	resolves with 4194304 bytes
after	UND_ERR_RES_EXCEEDED_MAX_SIZE	UND_ERR_RES_EXCEEDED_MAX_SIZE

Same split for a streaming consumer: over h1 the body errors mid-stream, over h2 it just completes.

The enforcement path itself isn't a regression, h2 has never honoured the option: git log -S kMaxResponseSize -- lib/dispatcher/client-h2.js is empty, and 7.29.0 ignores it too once you pass allowH2: true.

What did change is what an ordinary caller gets. Against a TLS origin offering h2, with h2 mentioned nowhere in the code:

constagent=newAgent({maxResponseSize: 1024})awaitrequest(url,{dispatcher: agent})

	7.29.0	8.10.0
plain new Agent({ maxResponseSize })	UND_ERR_RES_EXCEEDED_MAX_SIZE	resolves, 4194304 bytes
connect: { allowH2: false }	UND_ERR_RES_EXCEEDED_MAX_SIZE	UND_ERR_RES_EXCEEDED_MAX_SIZE

That's #4828 making allowH2 default to true. Opting out of h2 brings the limit back, which is the clearest sign of where it goes missing.

Changes

onData() counts bytes against maxResponseSize, mirroring onBody() in client-h1.js. The counter and the limit live on the pre-shaped per-request state object, so the hidden class is unchanged.

One deliberate difference from h1, and I'd like a second opinion on it. client-h1.js calls util.destroy(socket, ...) because HTTP/1.1 can't abandon one response without losing framing. Over h2 that would take out every sibling stream on the session, so this calls the existing per-request state.abort() instead, which resets only the offending stream. I verified the session survives: after an oversized stream is reset, later requests on the same client still succeed and the server reports one connection.

Tests

Two cases added to test/max-response-size.js, which was http/1.1 only. Both fail before the change (the oversized response resolves instead of throwing) and pass after:

• an h2c response over the limit rejects with ResponseExceededMaxSizeError
• the session stays usable, an oversized stream errors, a following request on the same client succeeds, and the server sees one connection

test/max-response-size.js: 6 pass. test/http2*.js test/h2c-client.js: 105 pass, 0 fail. The default (-1) path is unchanged, a 4 MiB body is still delivered in full with no limit set and with maxResponseSize: -1.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.47%. Comparing base (8f9cc1d) to head (2392304).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #5676 +/- ##
==========================================
+ Coverage 93.46% 93.47% +0.01% 
==========================================
Files 110 110 Lines 38777 38791 +14 ==========================================
+ Hits 36241 36258 +17 + Misses 2536 2533 -3 

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 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

[ondraulehla]

This relates to...

Nothing filed. I noticed it while reading the two client implementations side by side after #5638.

Rationale

maxResponseSize is documented on the HTTP/2 client's own page, docs/docs/api/H2CClient.md:

maxResponseSize {number} The maximum allowed response body size in bytes. Use -1 to disable. Default: -1.

It is declared in types/h2c-client.d.ts and validated in lib/dispatcher/client.js (an H2CClient with maxResponseSize: -5 throws InvalidArgumentError), then stored into client[kMaxResponseSize]. lib/dispatcher/client-h2.js never reads that symbol, so the value is validated and then ignored. onData() forwards every chunk to request.onResponseData(chunk) with no byte accounting.

Server sends 4 MiB, client asks for maxResponseSize: 1024:

	HTTP/1.1 Client	h2c H2CClient
before	UND_ERR_RES_EXCEEDED_MAX_SIZE	resolves with 4194304 bytes
after	UND_ERR_RES_EXCEEDED_MAX_SIZE	UND_ERR_RES_EXCEEDED_MAX_SIZE

Same split for a streaming consumer: over h1 the body errors mid-stream, over h2 it just completes.

The enforcement path itself isn't a regression, h2 has never honoured the option: git log -S kMaxResponseSize -- lib/dispatcher/client-h2.js is empty, and 7.29.0 ignores it too once you pass allowH2: true.

What did change is what an ordinary caller gets. Against a TLS origin offering h2, with h2 mentioned nowhere in the code:

constagent=newAgent({maxResponseSize: 1024})awaitrequest(url,{dispatcher: agent})

	7.29.0	8.10.0
plain new Agent({ maxResponseSize })	UND_ERR_RES_EXCEEDED_MAX_SIZE	resolves, 4194304 bytes
connect: { allowH2: false }	UND_ERR_RES_EXCEEDED_MAX_SIZE	UND_ERR_RES_EXCEEDED_MAX_SIZE

That's #4828 making allowH2 default to true. Opting out of h2 brings the limit back, which is the clearest sign of where it goes missing.

Changes

onData() counts bytes against maxResponseSize, mirroring onBody() in client-h1.js. The counter and the limit live on the pre-shaped per-request state object, so the hidden class is unchanged.

One deliberate difference from h1, and I'd like a second opinion on it. client-h1.js calls util.destroy(socket, ...) because HTTP/1.1 can't abandon one response without losing framing. Over h2 that would take out every sibling stream on the session, so this calls the existing per-request state.abort() instead, which resets only the offending stream. I verified the session survives: after an oversized stream is reset, later requests on the same client still succeed and the server reports one connection.

Tests

Two cases added to test/max-response-size.js, which was http/1.1 only. Both fail before the change (the oversized response resolves instead of throwing) and pass after:

• an h2c response over the limit rejects with ResponseExceededMaxSizeError
• the session stays usable, an oversized stream errors, a following request on the same client succeeds, and the server sees one connection

test/max-response-size.js: 6 pass. test/http2*.js test/h2c-client.js: 105 pass, 0 fail. The default (-1) path is unchanged, a 4 MiB body is still delivered in full with no limit set and with maxResponseSize: -1.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.47%. Comparing base (8f9cc1d) to head (2392304).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #5676 +/- ##
==========================================
+ Coverage 93.46% 93.47% +0.01% 
==========================================
Files 110 110 Lines 38777 38791 +14 ==========================================
+ Hits 36241 36258 +17 + Misses 2536 2533 -3 

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 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

[ondraulehla]

This relates to...

Nothing filed. I noticed it while reading the two client implementations side by side after #5638.

Rationale

maxResponseSize is documented on the HTTP/2 client's own page, docs/docs/api/H2CClient.md:

maxResponseSize {number} The maximum allowed response body size in bytes. Use -1 to disable. Default: -1.

It is declared in types/h2c-client.d.ts and validated in lib/dispatcher/client.js (an H2CClient with maxResponseSize: -5 throws InvalidArgumentError), then stored into client[kMaxResponseSize]. lib/dispatcher/client-h2.js never reads that symbol, so the value is validated and then ignored. onData() forwards every chunk to request.onResponseData(chunk) with no byte accounting.

Server sends 4 MiB, client asks for maxResponseSize: 1024:

	HTTP/1.1 Client	h2c H2CClient
before	UND_ERR_RES_EXCEEDED_MAX_SIZE	resolves with 4194304 bytes
after	UND_ERR_RES_EXCEEDED_MAX_SIZE	UND_ERR_RES_EXCEEDED_MAX_SIZE

Same split for a streaming consumer: over h1 the body errors mid-stream, over h2 it just completes.

The enforcement path itself isn't a regression, h2 has never honoured the option: git log -S kMaxResponseSize -- lib/dispatcher/client-h2.js is empty, and 7.29.0 ignores it too once you pass allowH2: true.

What did change is what an ordinary caller gets. Against a TLS origin offering h2, with h2 mentioned nowhere in the code:

constagent=newAgent({maxResponseSize: 1024})awaitrequest(url,{dispatcher: agent})

	7.29.0	8.10.0
plain new Agent({ maxResponseSize })	UND_ERR_RES_EXCEEDED_MAX_SIZE	resolves, 4194304 bytes
connect: { allowH2: false }	UND_ERR_RES_EXCEEDED_MAX_SIZE	UND_ERR_RES_EXCEEDED_MAX_SIZE

That's #4828 making allowH2 default to true. Opting out of h2 brings the limit back, which is the clearest sign of where it goes missing.

Changes

onData() counts bytes against maxResponseSize, mirroring onBody() in client-h1.js. The counter and the limit live on the pre-shaped per-request state object, so the hidden class is unchanged.

One deliberate difference from h1, and I'd like a second opinion on it. client-h1.js calls util.destroy(socket, ...) because HTTP/1.1 can't abandon one response without losing framing. Over h2 that would take out every sibling stream on the session, so this calls the existing per-request state.abort() instead, which resets only the offending stream. I verified the session survives: after an oversized stream is reset, later requests on the same client still succeed and the server reports one connection.

Tests

Two cases added to test/max-response-size.js, which was http/1.1 only. Both fail before the change (the oversized response resolves instead of throwing) and pass after:

• an h2c response over the limit rejects with ResponseExceededMaxSizeError
• the session stays usable, an oversized stream errors, a following request on the same client succeeds, and the server sees one connection

test/max-response-size.js: 6 pass. test/http2*.js test/h2c-client.js: 105 pass, 0 fail. The default (-1) path is unchanged, a 4 MiB body is still delivered in full with no limit set and with maxResponseSize: -1.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.47%. Comparing base (8f9cc1d) to head (2392304).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #5676 +/- ##
==========================================
+ Coverage 93.46% 93.47% +0.01% 
==========================================
Files 110 110 Lines 38777 38791 +14 ==========================================
+ Hits 36241 36258 +17 + Misses 2536 2533 -3 

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 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

[ondraulehla]

This relates to...

Nothing filed. I noticed it while reading the two client implementations side by side after #5638.

Rationale

maxResponseSize is documented on the HTTP/2 client's own page, docs/docs/api/H2CClient.md:

maxResponseSize {number} The maximum allowed response body size in bytes. Use -1 to disable. Default: -1.

It is declared in types/h2c-client.d.ts and validated in lib/dispatcher/client.js (an H2CClient with maxResponseSize: -5 throws InvalidArgumentError), then stored into client[kMaxResponseSize]. lib/dispatcher/client-h2.js never reads that symbol, so the value is validated and then ignored. onData() forwards every chunk to request.onResponseData(chunk) with no byte accounting.

Server sends 4 MiB, client asks for maxResponseSize: 1024:

	HTTP/1.1 Client	h2c H2CClient
before	UND_ERR_RES_EXCEEDED_MAX_SIZE	resolves with 4194304 bytes
after	UND_ERR_RES_EXCEEDED_MAX_SIZE	UND_ERR_RES_EXCEEDED_MAX_SIZE

Same split for a streaming consumer: over h1 the body errors mid-stream, over h2 it just completes.

The enforcement path itself isn't a regression, h2 has never honoured the option: git log -S kMaxResponseSize -- lib/dispatcher/client-h2.js is empty, and 7.29.0 ignores it too once you pass allowH2: true.

What did change is what an ordinary caller gets. Against a TLS origin offering h2, with h2 mentioned nowhere in the code:

constagent=newAgent({maxResponseSize: 1024})awaitrequest(url,{dispatcher: agent})

	7.29.0	8.10.0
plain new Agent({ maxResponseSize })	UND_ERR_RES_EXCEEDED_MAX_SIZE	resolves, 4194304 bytes
connect: { allowH2: false }	UND_ERR_RES_EXCEEDED_MAX_SIZE	UND_ERR_RES_EXCEEDED_MAX_SIZE

That's #4828 making allowH2 default to true. Opting out of h2 brings the limit back, which is the clearest sign of where it goes missing.

Changes

onData() counts bytes against maxResponseSize, mirroring onBody() in client-h1.js. The counter and the limit live on the pre-shaped per-request state object, so the hidden class is unchanged.

One deliberate difference from h1, and I'd like a second opinion on it. client-h1.js calls util.destroy(socket, ...) because HTTP/1.1 can't abandon one response without losing framing. Over h2 that would take out every sibling stream on the session, so this calls the existing per-request state.abort() instead, which resets only the offending stream. I verified the session survives: after an oversized stream is reset, later requests on the same client still succeed and the server reports one connection.

Tests

Two cases added to test/max-response-size.js, which was http/1.1 only. Both fail before the change (the oversized response resolves instead of throwing) and pass after:

• an h2c response over the limit rejects with ResponseExceededMaxSizeError
• the session stays usable, an oversized stream errors, a following request on the same client succeeds, and the server sees one connection

test/max-response-size.js: 6 pass. test/http2*.js test/h2c-client.js: 105 pass, 0 fail. The default (-1) path is unchanged, a 4 MiB body is still delivered in full with no limit set and with maxResponseSize: -1.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.47%. Comparing base (8f9cc1d) to head (2392304).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #5676 +/- ##
==========================================
+ Coverage 93.46% 93.47% +0.01% 
==========================================
Files 110 110 Lines 38777 38791 +14 ==========================================
+ Hits 36241 36258 +17 + Misses 2536 2533 -3 

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 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

[ondraulehla]

This relates to...

Nothing filed. I noticed it while reading the two client implementations side by side after #5638.

Rationale

maxResponseSize is documented on the HTTP/2 client's own page, docs/docs/api/H2CClient.md:

maxResponseSize {number} The maximum allowed response body size in bytes. Use -1 to disable. Default: -1.

It is declared in types/h2c-client.d.ts and validated in lib/dispatcher/client.js (an H2CClient with maxResponseSize: -5 throws InvalidArgumentError), then stored into client[kMaxResponseSize]. lib/dispatcher/client-h2.js never reads that symbol, so the value is validated and then ignored. onData() forwards every chunk to request.onResponseData(chunk) with no byte accounting.

Server sends 4 MiB, client asks for maxResponseSize: 1024:

	HTTP/1.1 Client	h2c H2CClient
before	UND_ERR_RES_EXCEEDED_MAX_SIZE	resolves with 4194304 bytes
after	UND_ERR_RES_EXCEEDED_MAX_SIZE	UND_ERR_RES_EXCEEDED_MAX_SIZE

Same split for a streaming consumer: over h1 the body errors mid-stream, over h2 it just completes.

The enforcement path itself isn't a regression, h2 has never honoured the option: git log -S kMaxResponseSize -- lib/dispatcher/client-h2.js is empty, and 7.29.0 ignores it too once you pass allowH2: true.

What did change is what an ordinary caller gets. Against a TLS origin offering h2, with h2 mentioned nowhere in the code:

constagent=newAgent({maxResponseSize: 1024})awaitrequest(url,{dispatcher: agent})

	7.29.0	8.10.0
plain new Agent({ maxResponseSize })	UND_ERR_RES_EXCEEDED_MAX_SIZE	resolves, 4194304 bytes
connect: { allowH2: false }	UND_ERR_RES_EXCEEDED_MAX_SIZE	UND_ERR_RES_EXCEEDED_MAX_SIZE

That's #4828 making allowH2 default to true. Opting out of h2 brings the limit back, which is the clearest sign of where it goes missing.

Changes

onData() counts bytes against maxResponseSize, mirroring onBody() in client-h1.js. The counter and the limit live on the pre-shaped per-request state object, so the hidden class is unchanged.

One deliberate difference from h1, and I'd like a second opinion on it. client-h1.js calls util.destroy(socket, ...) because HTTP/1.1 can't abandon one response without losing framing. Over h2 that would take out every sibling stream on the session, so this calls the existing per-request state.abort() instead, which resets only the offending stream. I verified the session survives: after an oversized stream is reset, later requests on the same client still succeed and the server reports one connection.

Tests

Two cases added to test/max-response-size.js, which was http/1.1 only. Both fail before the change (the oversized response resolves instead of throwing) and pass after:

• an h2c response over the limit rejects with ResponseExceededMaxSizeError
• the session stays usable, an oversized stream errors, a following request on the same client succeeds, and the server sees one connection

test/max-response-size.js: 6 pass. test/http2*.js test/h2c-client.js: 105 pass, 0 fail. The default (-1) path is unchanged, a 4 MiB body is still delivered in full with no limit set and with maxResponseSize: -1.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.47%. Comparing base (8f9cc1d) to head (2392304).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #5676 +/- ##
==========================================
+ Coverage 93.46% 93.47% +0.01% 
==========================================
Files 110 110 Lines 38777 38791 +14 ==========================================
+ Hits 36241 36258 +17 + Misses 2536 2533 -3 

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 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

[ondraulehla]

This relates to...

Nothing filed. I noticed it while reading the two client implementations side by side after #5638.

Rationale

maxResponseSize is documented on the HTTP/2 client's own page, docs/docs/api/H2CClient.md:

maxResponseSize {number} The maximum allowed response body size in bytes. Use -1 to disable. Default: -1.

It is declared in types/h2c-client.d.ts and validated in lib/dispatcher/client.js (an H2CClient with maxResponseSize: -5 throws InvalidArgumentError), then stored into client[kMaxResponseSize]. lib/dispatcher/client-h2.js never reads that symbol, so the value is validated and then ignored. onData() forwards every chunk to request.onResponseData(chunk) with no byte accounting.

Server sends 4 MiB, client asks for maxResponseSize: 1024:

	HTTP/1.1 Client	h2c H2CClient
before	UND_ERR_RES_EXCEEDED_MAX_SIZE	resolves with 4194304 bytes
after	UND_ERR_RES_EXCEEDED_MAX_SIZE	UND_ERR_RES_EXCEEDED_MAX_SIZE

Same split for a streaming consumer: over h1 the body errors mid-stream, over h2 it just completes.

The enforcement path itself isn't a regression, h2 has never honoured the option: git log -S kMaxResponseSize -- lib/dispatcher/client-h2.js is empty, and 7.29.0 ignores it too once you pass allowH2: true.

What did change is what an ordinary caller gets. Against a TLS origin offering h2, with h2 mentioned nowhere in the code:

constagent=newAgent({maxResponseSize: 1024})awaitrequest(url,{dispatcher: agent})

	7.29.0	8.10.0
plain new Agent({ maxResponseSize })	UND_ERR_RES_EXCEEDED_MAX_SIZE	resolves, 4194304 bytes
connect: { allowH2: false }	UND_ERR_RES_EXCEEDED_MAX_SIZE	UND_ERR_RES_EXCEEDED_MAX_SIZE

That's #4828 making allowH2 default to true. Opting out of h2 brings the limit back, which is the clearest sign of where it goes missing.

Changes

onData() counts bytes against maxResponseSize, mirroring onBody() in client-h1.js. The counter and the limit live on the pre-shaped per-request state object, so the hidden class is unchanged.

One deliberate difference from h1, and I'd like a second opinion on it. client-h1.js calls util.destroy(socket, ...) because HTTP/1.1 can't abandon one response without losing framing. Over h2 that would take out every sibling stream on the session, so this calls the existing per-request state.abort() instead, which resets only the offending stream. I verified the session survives: after an oversized stream is reset, later requests on the same client still succeed and the server reports one connection.

Tests

Two cases added to test/max-response-size.js, which was http/1.1 only. Both fail before the change (the oversized response resolves instead of throwing) and pass after:

• an h2c response over the limit rejects with ResponseExceededMaxSizeError
• the session stays usable, an oversized stream errors, a following request on the same client succeeds, and the server sees one connection

test/max-response-size.js: 6 pass. test/http2*.js test/h2c-client.js: 105 pass, 0 fail. The default (-1) path is unchanged, a 4 MiB body is still delivered in full with no limit set and with maxResponseSize: -1.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.47%. Comparing base (8f9cc1d) to head (2392304).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #5676 +/- ##
==========================================
+ Coverage 93.46% 93.47% +0.01% 
==========================================
Files 110 110 Lines 38777 38791 +14 ==========================================
+ Hits 36241 36258 +17 + Misses 2536 2533 -3 

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 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

[ondraulehla]

This relates to...

Nothing filed. I noticed it while reading the two client implementations side by side after #5638.

Rationale

maxResponseSize is documented on the HTTP/2 client's own page, docs/docs/api/H2CClient.md:

maxResponseSize {number} The maximum allowed response body size in bytes. Use -1 to disable. Default: -1.

It is declared in types/h2c-client.d.ts and validated in lib/dispatcher/client.js (an H2CClient with maxResponseSize: -5 throws InvalidArgumentError), then stored into client[kMaxResponseSize]. lib/dispatcher/client-h2.js never reads that symbol, so the value is validated and then ignored. onData() forwards every chunk to request.onResponseData(chunk) with no byte accounting.

Server sends 4 MiB, client asks for maxResponseSize: 1024:

	HTTP/1.1 Client	h2c H2CClient
before	UND_ERR_RES_EXCEEDED_MAX_SIZE	resolves with 4194304 bytes
after	UND_ERR_RES_EXCEEDED_MAX_SIZE	UND_ERR_RES_EXCEEDED_MAX_SIZE

Same split for a streaming consumer: over h1 the body errors mid-stream, over h2 it just completes.

The enforcement path itself isn't a regression, h2 has never honoured the option: git log -S kMaxResponseSize -- lib/dispatcher/client-h2.js is empty, and 7.29.0 ignores it too once you pass allowH2: true.

What did change is what an ordinary caller gets. Against a TLS origin offering h2, with h2 mentioned nowhere in the code:

constagent=newAgent({maxResponseSize: 1024})awaitrequest(url,{dispatcher: agent})

	7.29.0	8.10.0
plain new Agent({ maxResponseSize })	UND_ERR_RES_EXCEEDED_MAX_SIZE	resolves, 4194304 bytes
connect: { allowH2: false }	UND_ERR_RES_EXCEEDED_MAX_SIZE	UND_ERR_RES_EXCEEDED_MAX_SIZE

That's #4828 making allowH2 default to true. Opting out of h2 brings the limit back, which is the clearest sign of where it goes missing.

Changes

onData() counts bytes against maxResponseSize, mirroring onBody() in client-h1.js. The counter and the limit live on the pre-shaped per-request state object, so the hidden class is unchanged.

One deliberate difference from h1, and I'd like a second opinion on it. client-h1.js calls util.destroy(socket, ...) because HTTP/1.1 can't abandon one response without losing framing. Over h2 that would take out every sibling stream on the session, so this calls the existing per-request state.abort() instead, which resets only the offending stream. I verified the session survives: after an oversized stream is reset, later requests on the same client still succeed and the server reports one connection.

Tests

Two cases added to test/max-response-size.js, which was http/1.1 only. Both fail before the change (the oversized response resolves instead of throwing) and pass after:

• an h2c response over the limit rejects with ResponseExceededMaxSizeError
• the session stays usable, an oversized stream errors, a following request on the same client succeeds, and the server sees one connection

test/max-response-size.js: 6 pass. test/http2*.js test/h2c-client.js: 105 pass, 0 fail. The default (-1) path is unchanged, a 4 MiB body is still delivered in full with no limit set and with maxResponseSize: -1.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.47%. Comparing base (8f9cc1d) to head (2392304).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #5676 +/- ##
==========================================
+ Coverage 93.46% 93.47% +0.01% 
==========================================
Files 110 110 Lines 38777 38791 +14 ==========================================
+ Hits 36241 36258 +17 + Misses 2536 2533 -3 

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 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

[ondraulehla]

This relates to...

Nothing filed. I noticed it while reading the two client implementations side by side after #5638.

Rationale

maxResponseSize is documented on the HTTP/2 client's own page, docs/docs/api/H2CClient.md:

maxResponseSize {number} The maximum allowed response body size in bytes. Use -1 to disable. Default: -1.

It is declared in types/h2c-client.d.ts and validated in lib/dispatcher/client.js (an H2CClient with maxResponseSize: -5 throws InvalidArgumentError), then stored into client[kMaxResponseSize]. lib/dispatcher/client-h2.js never reads that symbol, so the value is validated and then ignored. onData() forwards every chunk to request.onResponseData(chunk) with no byte accounting.

Server sends 4 MiB, client asks for maxResponseSize: 1024:

	HTTP/1.1 Client	h2c H2CClient
before	UND_ERR_RES_EXCEEDED_MAX_SIZE	resolves with 4194304 bytes
after	UND_ERR_RES_EXCEEDED_MAX_SIZE	UND_ERR_RES_EXCEEDED_MAX_SIZE

Same split for a streaming consumer: over h1 the body errors mid-stream, over h2 it just completes.

The enforcement path itself isn't a regression, h2 has never honoured the option: git log -S kMaxResponseSize -- lib/dispatcher/client-h2.js is empty, and 7.29.0 ignores it too once you pass allowH2: true.

What did change is what an ordinary caller gets. Against a TLS origin offering h2, with h2 mentioned nowhere in the code:

constagent=newAgent({maxResponseSize: 1024})awaitrequest(url,{dispatcher: agent})

	7.29.0	8.10.0
plain new Agent({ maxResponseSize })	UND_ERR_RES_EXCEEDED_MAX_SIZE	resolves, 4194304 bytes
connect: { allowH2: false }	UND_ERR_RES_EXCEEDED_MAX_SIZE	UND_ERR_RES_EXCEEDED_MAX_SIZE

That's #4828 making allowH2 default to true. Opting out of h2 brings the limit back, which is the clearest sign of where it goes missing.

Changes

onData() counts bytes against maxResponseSize, mirroring onBody() in client-h1.js. The counter and the limit live on the pre-shaped per-request state object, so the hidden class is unchanged.

One deliberate difference from h1, and I'd like a second opinion on it. client-h1.js calls util.destroy(socket, ...) because HTTP/1.1 can't abandon one response without losing framing. Over h2 that would take out every sibling stream on the session, so this calls the existing per-request state.abort() instead, which resets only the offending stream. I verified the session survives: after an oversized stream is reset, later requests on the same client still succeed and the server reports one connection.

Tests

Two cases added to test/max-response-size.js, which was http/1.1 only. Both fail before the change (the oversized response resolves instead of throwing) and pass after:

• an h2c response over the limit rejects with ResponseExceededMaxSizeError
• the session stays usable, an oversized stream errors, a following request on the same client succeeds, and the server sees one connection

test/max-response-size.js: 6 pass. test/http2*.js test/h2c-client.js: 105 pass, 0 fail. The default (-1) path is unchanged, a 4 MiB body is still delivered in full with no limit set and with maxResponseSize: -1.

[codecov-commenter]

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 93.47%. Comparing base (8f9cc1d) to head (2392304).
⚠️ Report is 2 commits behind head on main.

Additional details and impacted files

@@ Coverage Diff @@## main #5676 +/- ##
==========================================
+ Coverage 93.46% 93.47% +0.01% 
==========================================
Files 110 110 Lines 38777 38791 +14 ==========================================
+ Hits 36241 36258 +17 + Misses 2536 2533 -3 

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 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