Version

v16.14.0

Platform

Linux chad1 5.4.0-99-generic #112~18.04.1-Ubuntu SMP Thu Feb 3 14:09:57 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

Subsystem

http net.Socket streams

What steps will reproduce the bug?

In this gist: https://gist.github.com/chad3814/b1f927c5cabae86fb2733f1ab37d6bfd
there are two files, listener.mjs and putter.mjs. If you run listener.mjs and then in another shell run putter.mjs you'll see that it saves an empty, zero byte file. Then if you remark the await sleep(10); on line 12 on listener.mjs and run them again, you'll see that it writes out the file on the first pass through the loop, but on the next pass an ECONNRESET is thrown.

How often does it reproduce? Is there a required condition?

Happens every time as discussed above

What is the expected behavior?

What it looks like to me is when the body of an http message is short, the header and body don't break the high water mark, so it's all read in at once and saved in the buffer list. The problem is triggered by the remote end not waiting for a response from the server and just closing the connection (which is allowed afaik by the http spec). I can understand an ECONNRESET being thrown, but we should be able to read the data from the body. Or maybe the error should be thrown if we/when we write to the response object? Either way, we need to reliably read the data using node 16 like we did with node 14.

What do you see instead?

I see this problem in our production code because ffmpeg does the same sort of http call as in putter.mjs, where it pushes all the data and then closes the connection without waiting for a response. This all worked in node 14 using .pipe()s but with node 16 and pipes we're seeing the two issues above at different times.

Additional information

No response