You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I updated from node 14 LTS to 20 LTS. Surprisingly only one issue has surfaced for me.
In 14 I was opening a read stream on the file requested and piping it directly to the response stream which by default calls the .end() on both streams unless otherwise configured, which worked nicely setting writeHead() more than once for over-writing scenarios without emitting an error if there was an error emitted from the read stream:
let readStream = fs.createReadStream(filePath);
response.writeHead(200, {"Content-Type":mediaType + "...(shortened for your eyes)"});
readStream.pipe(response);
readStream.on('error', function(error){
if(error.code == 'ENOENT')
{
response.writeHead(404, {"Content-Type":"text/plain; charset=utf-8"});
response.end('404 NOT FOUND', 'utf-8');
}
else if(error.code == 'EISDIR')
{
response.writeHead(403, {"Content-Type":"text/plain; charset=utf-8"});
response.end('403 FORBIDDEN', 'utf-8');
}
else
{
response.writeHead(500, {"Content-Type":"text/plain; charset=utf-8"});
response.end('500 SERVER ERROR', 'utf-8');
}
});
This allowed for clean minimal code and worked very well. However I looked into the history of changes and noticed that writeHead() now emits this error after consecutive calls. Which I understand the reason and agree with it as it is intended to be called once (if it causes issues somewhere else).
A minor inconvenience but it definitely complicates the process now as the stream piping has to be dissected/expanded to inject the writeHead once before the response.end() call. Especially since the docs recommend not to use exists/access/open to pre-check if the file exists. It recommends handling it from the stream error event when fired as I do above.
QUESTION: I am curious, was there any detriment to calling response.writeHead multiple times? What side-effects were there? I hadn't noticed anything above the hood.
EDIT: I opened up a feature request to keep the current changes but to add a response.overwriteHead function for these error handling scenarios. #52026
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
I updated from node 14 LTS to 20 LTS. Surprisingly only one issue has surfaced for me.
In 14 I was opening a read stream on the file requested and piping it directly to the response stream which by default calls the .end() on both streams unless otherwise configured, which worked nicely setting writeHead() more than once for over-writing scenarios without emitting an error if there was an error emitted from the read stream:
This allowed for clean minimal code and worked very well. However I looked into the history of changes and noticed that writeHead() now emits this error after consecutive calls. Which I understand the reason and agree with it as it is intended to be called once (if it causes issues somewhere else).
A minor inconvenience but it definitely complicates the process now as the stream piping has to be dissected/expanded to inject the writeHead once before the response.end() call. Especially since the docs recommend not to use exists/access/open to pre-check if the file exists. It recommends handling it from the stream error event when fired as I do above.
QUESTION: I am curious, was there any detriment to calling response.writeHead multiple times? What side-effects were there? I hadn't noticed anything above the hood.
EDIT: I opened up a feature request to keep the current changes but to add a response.overwriteHead function for these error handling scenarios. #52026
Beta Was this translation helpful? Give feedback.
All reactions