-
Notifications
You must be signed in to change notification settings - Fork 30k
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: don't write error to socket #34465
Conversation
Maybe a bit too strict but figuring out whether it's actually safe to write to the socket or not is non trivial. |
The state of the connection is unknown at this point and writing to it can corrupt client state before it is aware of an error.
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.
It's best effort, I don't think we should change this.
Why? It can corrupt responses without the client being able to detect it? |
What is the advantage in removing the response? It's a single chunk which is written in a single write with no other pending writes. |
I haven't followed the code fully but I believe e.g. bad response could be written after the http headers are written and be parsed as part of the http response body. In the case of 'upgrade' (websocket) and 'connect' I'm not sure what actually happens. |
@nodejs/http |
On upgrade the parser is freed and the |
Cool. That leaves the after headers are written scenario. |
I don't have specific opinion to add to this PR, but just wanted to link the original PR #15324 that added the first response writing if any of the conversation from that thread helps here. |
I do not remember any bug report opened for this scenario. Do you mean something like this?
|
Ok. Changed to only write if nothing else has been written to the socket. |
There is non as far as I know.
The socket emits 'error' at any point after the headers has been written and the body has not yet completed writing. Writes can still succeed after |
Looks better now. |
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.
lgtm
I think the 'clientError' event documentation should be updated too https://nodejs.org/api/http.html#http_event_clienterror |
@wa-Nadoo PTAL |
Landed in e8d7fed |
The state of the connection is unknown at this point and writing to it can corrupt client state before it is aware of an error. PR-URL: #34465 Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
This change is breaking a test on v14.x
Any idea what's going on? Should this be backported? |
The state of the connection is unknown at this point and writing to it can corrupt client state before it is aware of an error. PR-URL: #34465 Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
The state of the connection is unknown at this point and writing to it can corrupt client state before it is aware of an error. PR-URL: #34465 Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
The state of the connection is unknown at this point and writing to it can corrupt client state before it is aware of an error. PR-URL: #34465 Reviewed-By: Luigi Pinca <luigipinca@gmail.com> Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: James M Snell <jasnell@gmail.com>
The state of the connection is unknown at this point and
writing to it can corrupt client state before it is aware
of an error.
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passes