Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

http: detach socket from IncomingMessage on keep-alive #32153

Closed
wants to merge 1 commit into from

Conversation

ronag
Copy link
Member

@ronag ronag commented Mar 8, 2020

If the socket is not detached then a future call to res.destroy
(through e.g. pipeline) would unecessarily kill the socket while
its in the agent free list.

Checklist
  • make -j4 test (UNIX), or vcbuild test (Windows) passes
  • tests and/or benchmarks are included
  • documentation is changed or added
  • commit message follows commit guidelines

@ronag ronag added the http Issues or PRs related to the http subsystem. label Mar 8, 2020
@ronag
Copy link
Member Author

ronag commented Mar 8, 2020

@szmarczak I think this is the fix you were looking for.

@ronag ronag added the semver-major PRs that contain breaking changes and should be released in the next major version. label Mar 8, 2020
@ronag
Copy link
Member Author

ronag commented Mar 8, 2020

I'm not sure whether setting socket to null here can cause more breakage... but it does make sense to set it to null. Also given the quote above IncomingMessage.destroy

// It's possible that the socket will be destroyed, and removed from
// any messages, before ever calling this.  In that case, just skip
// it, since something else is destroying this connection anyway.

@szmarczak
Copy link
Member

Looks amazing, you're a lifesaver!

If the socket is not detached then a future call to res.destroy
(through e.g. pipeline) would unecessarily kill the socket while
its in the agent free list.
@ronag ronag changed the title stream: detach socket from IncomingMessage on keep-alive http: detach socket from IncomingMessage on keep-alive Mar 8, 2020
@addaleax
Copy link
Member

addaleax commented Mar 9, 2020

@nodejs-github-bot
Copy link
Collaborator

@BridgeAR BridgeAR added the author ready PRs that have at least one approval, no pending requests for changes, and a CI started. label Mar 9, 2020
@ronag
Copy link
Member Author

ronag commented Mar 10, 2020

CITGM looks good

ronag added a commit that referenced this pull request Mar 10, 2020
If the socket is not detached then a future call to res.destroy
(through e.g. pipeline) would unecessarily kill the socket while
its in the agent free list.

PR-URL: #32153
Reviewed-By: Anna Henningsen <[email protected]>
Reviewed-By: James M Snell <[email protected]>
@ronag
Copy link
Member Author

ronag commented Mar 10, 2020

Landed in c1b2f6a

@ronag ronag closed this Mar 10, 2020
@szmarczak
Copy link
Member

Since this isn't a breaking change, will this be backported?

@ronag
Copy link
Member Author

ronag commented Mar 11, 2020

@szmarczak it's labeled as semver-major, sorry :(

hyj1991 added a commit to hyj1991/urllib that referenced this pull request May 14, 2020
res.socket has been detached from IncomingMessage in node-v14.x

Reference: nodejs/node#32153
hyj1991 added a commit to hyj1991/urllib that referenced this pull request May 14, 2020
res.socket has been detached from IncomingMessage in node-v14.x

Reference: nodejs/node#32153
fengmk2 pushed a commit to node-modules/urllib that referenced this pull request May 15, 2020
res.socket has been detached from IncomingMessage in node-v14.x

Reference: nodejs/node#32153
@@ -48,7 +48,7 @@ const server = http.createServer(common.mustCall((req, res) => {
response.on('end', common.mustCall(() => {
request1.socket.destroy();

response.socket.once('close', common.mustCall(() => {
request1.socket.once('close', common.mustCall(() => {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks like it's no longer testing what it used to be testing (just working around the fact that response.socket is cleared now by attaching the event to an unrelated socket?). Proper fix would be to leave the event on response.socket and just attach it before the socket is cleared (up 3 lines, right after response.pipe)?

I'm not actually familiar with this code, just in here since this test started breaking on Node v14 over in http-parser-js, which has a fork of some of these tests, but I noticed the old code also had a big comment about how important the timing/ordering of attaching that event listener was.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
author ready PRs that have at least one approval, no pending requests for changes, and a CI started. http Issues or PRs related to the http subsystem. semver-major PRs that contain breaking changes and should be released in the next major version.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants