Repository navigation
Conversation
Per RFC 9112 section 6.3, responses to HEAD requests, and 204 and 304 responses, cannot contain a message body. When such a response is complete and nobody has started reading it, release its socket back to the agent's free pool instead of waiting for an 'end' that only a reader can cause. Refs: nodejs#47228 Assisted-by: claude:sonnet-5.5 Signed-off-by: Matt Weber <hello@mweber.xyz>
Collaborator
|
Review requested:
|
nodejs-github-bot
added
http
Contributor
|
Welcome to Node.js, and thank you for your first contribution! Before review, please take a moment to read:
Please make sure every commit is signed off. For a first pull request, GitHub Actions require collaborator approval and Jenkins CI must be started by a collaborator or triager, so an initial wait is normal. |
A response that has been received completely but that nobody reads keeps its socket busy, and the socket keeps the process alive until the server closes the connection. Once nothing else is keeping the event loop alive, nothing is left that could read the response, so unref the socket in that case instead of waiting for the connection to close. This only applies while nobody has started reading. A response that is read later is still delivered as before, and a request that is still in flight keeps the process alive. As with any unref'd handle, the process may now exit before the server closes the connection, in which case 'close' is not emitted. Fixes: nodejs#47228 Assisted-by: claude:sonnet-5.5 Signed-off-by: Matt Weber <hello@mweber.xyz>
mweberxyz
changed the title
mweberxyz
changed the title
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
2 participants
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.
An http response that isn't read currently keeps its socket busy (and doesn't return to the keepAlive pool), and keeps the process alive, until the server closes the connection.
http: free socket when response cannot have a body: HEAD, 204 and 304 responses cannot have a body (RFC 9112, section 6.3). When one is complete and unread, its socket is now released to the agent immediately instead of waiting for an'end'that only a reader can cause.http: unref socket of a complete unread response: any other complete, unread response may have a body, so its socket is unref'd instead, and it alone no longer keeps the process alive. A response read later is still delivered.Fixes: #47228
Behavior to be aware of
'end'is still only emitted to callers that read the response.await),res.socketisnulland the request's'close'comes before the response's'end'.'close'is not emitted. Those sockets stay busy in the agent until read or closed, so only HEAD/204/304 go back to the pool.Tests
test-http-agent-exit.js(carried over from http: resume kept-alive when no body allowed #52329): unread HEAD, 204 and 304 requests must not block exit, and readers still get'end'and no'data'.test-http-agent-unread-response-exit.js(from this repro, thanks @jakebailey): the same for 200 and 302 responses, plus a response read 200 ms later still delivers its body.Both fail on Node 26.12.0 without this change.
This supersedes #52329 (which I left long abandoned, apologies): it resumed the response automatically and so changed event order and emitted
'end'for unread responses.AI assistance
Claude Code (claude:sonnet-5.5) helped explore the design, draft the code and tests, and run the build, lint and test suites. I reviewed and edited the changes and take responsibility for them. Claude also told me my PR description was bad and offered some improvements, the completely human authored draft is still in the history.