-
Notifications
You must be signed in to change notification settings - Fork 29.8k
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: fix missing close event on aborted response #1373
Conversation
When sending a response after client aborted the connection in the same tick when the socket is already destroyed but the socket-close event is still not delivered, you did not get either a response-finish or a response-close event. This fix of the race-condition needs an additional flag "_finishOrCloseEmitted" in OutgoingMessage.
cc @indutny? |
var testTickCount = 3; | ||
|
||
var server = http.createServer(function (req, res) { | ||
console.log('server: request'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
usually, passing tests should be silent; could you remove the expected console.log
s?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Of course I could remove them - I kept with the other tests which also contain console.log
s (output is hidden anyway in normal test run).
I thought, especially race conditions are much more understandable with some debugging output - also for future refactoring/debugging.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please keep them for now :) I've a bit delayed this, but going to review it next week!
See next commit for the actual fix. PR-URL: nodejs#1373 Reviewed-By: Fedor Indutny <[email protected]>
Do not detach the socket from the response until all data is actually sent to the other side. See: nodejs#1373
@not-implemented PTAL at #1411 . I have integrated your test, but decided to choose a bit different way to fix the issue. |
Thank you for discovering this! |
Ah very cool ... I didn't have the guts to delay the WHOLE finish-handling - only parts of it ;-) |
Thank you! |
See next commit for the actual fix. PR-URL: nodejs#1373 Reviewed-By: Fedor Indutny <[email protected]>
Do not detach the socket from the response until all data is actually sent to the other side. See: nodejs#1373
See next commit for the actual fix. PR-URL: nodejs#1373 Reviewed-By: Fedor Indutny <[email protected]>
Do not detach the socket from the response until all data is actually sent to the other side. See: nodejs#1373
Do not detach the socket from the response until all data is actually sent to the other side. See: #1373 PR-URL: #1411 Reviewed-By: Chris Dickinson <[email protected]> Reviewed-By: Jeremiah Senkpiel <[email protected]>
Do not detach the socket from the response until all data is actually sent to the other side. See: #1373 PR-URL: #1411 Reviewed-By: Chris Dickinson <[email protected]> Reviewed-By: Jeremiah Senkpiel <[email protected]>
See next commit for the actual fix. PR-URL: #1373 Reviewed-By: Fedor Indutny <[email protected]>
See next commit for the actual fix. PR-URL: #1373 Reviewed-By: Fedor Indutny <[email protected]>
Do not detach the socket from the response until all data is actually sent to the other side. See: #1373 PR-URL: #1411 Reviewed-By: Chris Dickinson <[email protected]> Reviewed-By: Jeremiah Senkpiel <[email protected]>
Do not detach the socket from the response until all data is actually sent to the other side. See: #1373 PR-URL: #1411 Reviewed-By: Chris Dickinson <[email protected]> Reviewed-By: Jeremiah Senkpiel <[email protected]>
Do not detach the socket from the response until all data is actually sent to the other side. See: #1373 PR-URL: #1411 Reviewed-By: Chris Dickinson <[email protected]> Reviewed-By: Jeremiah Senkpiel <[email protected]>
Do not detach the socket from the response until all data is actually sent to the other side. See: #1373 PR-URL: #1411 Reviewed-By: Chris Dickinson <[email protected]> Reviewed-By: Jeremiah Senkpiel <[email protected]>
Do not detach the socket from the response until all data is actually sent to the other side. See: #1373 PR-URL: #1411 Reviewed-By: Chris Dickinson <[email protected]> Reviewed-By: Jeremiah Senkpiel <[email protected]>
Do not detach the socket from the response until all data is actually sent to the other side. See: #1373 PR-URL: #1411 Reviewed-By: Chris Dickinson <[email protected]> Reviewed-By: Jeremiah Senkpiel <[email protected]>
Do not detach the socket from the response until all data is actually sent to the other side. See: #1373 PR-URL: #1411 Reviewed-By: Chris Dickinson <[email protected]> Reviewed-By: Jeremiah Senkpiel <[email protected]>
When sending a response after client aborted the connection in the same tick when the socket is already destroyed but the socket-close event is still not delivered, you did not get either a response-finish or a response-close event.
This fix of the race-condition needs an additional flag "_finishOrCloseEmitted" in OutgoingMessage.
I did not find any easier solution - I tried to fix this either with an additional "close" or an additional "finish" with some timing-tricks without an additional flag. I had no chance without breaking anything else.
Not all of the new checks of "_finishOrCloseEmitted" are currently really needed - they are just for completeness.