-
Notifications
You must be signed in to change notification settings - Fork 29.6k
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
Write after end when piping a ClientRequest to ServerResponse #14023
Labels
http
Issues or PRs related to the http subsystem.
Comments
3 tasks
Which version of |
@mcollina , Thanks. |
Fixed in 649d77b. |
addaleax
pushed a commit
that referenced
this issue
Jul 18, 2017
When an OutgoingMessage is closed (for example, using the `end` method), its 'writable' property should be changed to false - since it is not writable anymore. The 'writable' property should have the opposite value of the 'finished' property. PR-URL: #14024 Fixes: #14023 Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Fishrock123
pushed a commit
that referenced
this issue
Jul 19, 2017
When an OutgoingMessage is closed (for example, using the `end` method), its 'writable' property should be changed to false - since it is not writable anymore. The 'writable' property should have the opposite value of the 'finished' property. PR-URL: #14024 Fixes: #14023 Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
MylesBorins
pushed a commit
that referenced
this issue
Aug 16, 2017
When an OutgoingMessage is closed (for example, using the `end` method), its 'writable' property should be changed to false - since it is not writable anymore. The 'writable' property should have the opposite value of the 'finished' property. PR-URL: #14024 Fixes: #14023 Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
MylesBorins
pushed a commit
that referenced
this issue
Aug 16, 2017
When an OutgoingMessage is closed (for example, using the `end` method), its 'writable' property should be changed to false - since it is not writable anymore. The 'writable' property should have the opposite value of the 'finished' property. PR-URL: #14024 Fixes: #14023 Reviewed-By: Matteo Collina <matteo.collina@gmail.com> Reviewed-By: Gireesh Punathil <gpunathi@in.ibm.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hey,
I believe there is a minor issue in
_http_outgoing.js
code. In the constructor, the propertywritable
is changed totrue
(https://github.com/nodejs/node/blob/v4.x/lib/_http_outgoing.js#L64) :this.writable = true;
As of my understanding, this property is set in the constructor since
OutgoingMessage
inherits fromStream
, and inStream
's code, this property might be checked to validate that a stream is writable.However, this property is never changed to
false
in_http_outgoing.js
. Even when the message is closed (i.e. theend
method was called), this property remainstrue
.The class
OutgoingMessage
maintains another property,finished
, which indicates whether theOutgoingMessage
was finished already or not. In the constructorfinished
is set tofalse
, and later on, in theend
method, it is set to true. I believe thatfinished
andwritable
should have opposite values, since when aOutgoingMessage
is closed - it is notwritable
anymore and it isfinished
.This minor issue doesn't have much effect, but it might raise a lot of
write after end
errors, especially when piping. I can easily catch such errors so the process won't crash, but I guess the error shouldn't be raised in the first place.The following simple code reproduces this (note that I use the
request
npm):Server:
Client:
Simple output (of the server):
As you can see from the stack, we reach
stream.js
line 31. In line 30 (https://github.com/nodejs/node/blob/v4.x/lib/stream.js#L30) we can find the condition that should have failed:if (dest.writable) { ... }
So, if my
OutgoingMessage
'swritable
property was indeed changed to false once it was closed, the error wouldn't have been raised at all.Note that this probably happens due to race (between the client's request that was closed and the server's request, or actually the server-request's response, that got some new data), hence the code I attached doesn't reproduce this immediately and the output may not be the same as I attached.
I've opened a PR with a fix to this issue:
#14024
After applying this fix, my application works as expected and I never get any
write after end
errors in my scenario.Any help will be appreciated.
Thanks!
The text was updated successfully, but these errors were encountered: