Repository navigation
Duplicated response.writeHead calling is not checked in specific case #20932
Description
Activity
I also found that if you use different
statusCode(say 204) in first request and you areres.end('ok')later; that doesn't setTransfer-Encoding: chunkedin response and res.body is not sent.Though this doesn't work with
404or302.Either only
204screws res up or different classes of status code don't work with it.Full context available in #21289 and the referred link. In short:
Is this correct behavior?
Probably not, but given that there is an optimization to bypass header caching in the fast path, and given that calling
writeHeadtwice is inhibited in the documentation, I would say this is fine.I see.
I think, we confuse because there are two cases: a case that an error is thrown and a case that an error is not thrown when thewriteHeadis called twice.
Then, document should warn about that.
Also, the warning may help us. For example, node-static calls thewriteHeadtwice. Of course that is a bug of node-static, it is not a bug of Node.js. However, I had to read the source code of Node.js to find the bug of node-static because I didn't know why an error is not thrown, in almost cases.this has been documented with explanation to the behavior. Closing.
@gireeshpunathil can you link me to the doc change itself, or at least an updated version of the documentation?
Reacted by Tim@getify - sorry, I missed this question. the behavior difference between writeHead and setHeader w.r.t repeated header updates are documented here:
https://nodejs.org/dist/latest-v13.x/docs/api/http.html#http_response_setheader_name_value
hope this helps
That documentation does not, IMO, spell out an explanation or warning about the case listed here. I've read it several times and I still find it lacking in clarity.
Knowing this problem (from this issue), I can sorta infer that the bypass-caching-headers fast path optimization is the key to understanding this gotcha... but only barely. If I didn't know about this issue, it is not clear to me from reading the docs that you will get an error (on double call) only if you previously called setHeader. I still find that bizarre and the docs do not warn me about it.
When docs say "don't call this twice", a reasonable person expects that violating that will give an error. If there are optimizations in place that prevent an error from being displayed, such that the second call silently fails, this is a gotcha. And the docs do not warn about that gotcha.
@getify - thanks. I too read it many times now; and I admit something can be improved there, but not able to figure out how (I wrote those new sentences earlier) . Do you want to try phrasing something?
Reacted by Kyle Simpson
As it is documented,
response.writeHeadmethod should be called only once.When the
response.writeHeadmethod is called twice, an error ("Can't set headers after they are sent.") is thrown ifresponse.setHeadermethod was called. And the error is not thrown if theresponse.setHeadermethod was not called.For example:
Run this code as a server:
And run this code as a client (using request module):
That works fine without an error but the code as server calls the
response.writeHeadmethod twice.So, run this code as a server instead:
And run the client above.
Then, an error "Can't set headers after they are sent." is thrown.
Just only the
response.setHeadermethod was added to the second server.Is this correct behavior?
Of course the
response.writeHeadmethod should not be called again. However I feel strange about that it is checked only when theresponse.setHeadermethod was called.It seems that this issue is relevant to #8446, maybe. I take notice of an error that is thrown by the
response.setHeadermethod.In
OutgoingMessage.prototype.setHeader, the error is thrown if the headers are already sent (rendered).node/lib/_http_outgoing.js
Line 471 in 9a02de7
In
ServerResponse.prototype.writeHead, theOutgoingMessage.prototype.setHeaderis called only when current instance has header data (i.e. it hasthis[outHeadersKey]).node/lib/_http_server.js
Line 224 in 9a02de7
In other words, the
response.setHeadermethod that checks duplicated calling is called only when that method was already called (i.e.this[outHeadersKey]was already set).Also, duplicated calling is checked after headers were merged.
node/lib/_http_server.js
Line 234 in 9a02de7
I think that the checking should be moved to after
if ... else.That is, duplicated calling should be checked whether headers were merged or not.
Or, checking at top of
writeHeadis better because it has to do nothing when it throws an error.And also, it seems that there is another problem in that checking.
Run this code as a server instead:
This is the same as the code that throws an error except for last header name. However this does not throw an error.
After header were merged, duplicated calling is checked only when the last header name is
undefined.node/lib/_http_server.js
Line 234 in 9a02de7
A value of the
kwas updated repeatedly, and it has last header name or initial value. And duplicated calling is checked by theresponse.setHeadermethod in a loop only when thekis truthy.If the
k === undefinedmeans that theresponse.setHeadermethod never be called, that was not sufficient.I think that checking the
kis not needed (i.e.if (this._header) {) because duplicated calling can be checked even if that was already checked in theresponse.setHeadermethod.This problem also is solved by changing above, as I indicated.