Repository navigation
Conversation
When the peer reset a stream before sending END_STREAM, the compat `Http2ServerRequest` still pushed EOF from its 'close' handler, so it emitted 'end' for a truncated body (on main even after 'error' and 'close'). Unlike http1, where an aborted `IncomingMessage` is destroyed and never emits 'end', applications listening for 'end' then processed the partial body as if it were complete. Record in `onStreamClose()` that the peer closed the stream before END_STREAM, since `destroy()` ends the readable side afterwards, and destroy the request instead of ending it in that case. Requests whose body was complete before the reset still end normally. Signed-off-by: Matteo Collina <hello@matteocollina.com>
Collaborator
|
Review requested:
|
nodejs-github-bot
added
http2
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #67061 +/- ##
=======================================
Coverage 90.65% 90.65%
=======================================
Files 797 797
Lines 278268 278284 +16
Branches 53517 53518 +1
=======================================
+ Hits 252261 252283 +22
Misses 16386 16386
+ Partials 9621 9615 -6
🚀 New features to boost your workflow:
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
When a client resets a stream (
RST_STREAM, with any error code includingNO_ERROR) before sending END_STREAM, the compatHttp2ServerRequeststill pushes EOF from its'close'handler and emits'end'for the truncated body. On main,'end'even arrives after'error'and'close'.node:httpbehaves differently: an abortedIncomingMessageemits'aborted'and'error'(ECONNRESET) and is destroyed, never emitting'end'. Code that only listens for'end'therefore processes a partial HTTP/2 request body as if it were complete.onStreamClose()already knows whether the peer ended its side before closing, butdestroy()then ends the readable side, so the compat layer can't tell afterwards. This records it on the stream, and the compat request is destroyed instead of ended in that case. Requests whose body was complete before the reset still emit'end'as before, andrequest.completekeeps its documented semantics.This changes observable behavior for compat requests reset mid-body (no more
'end';stream.finished()and async iteration now report a premature close), so reviewers may want to weigh in on the semver label.