Closed
Description
Version
v16.7.0
Platform
Linux e332ae582690 5.10.47-linuxkit #1 SMP Sat Jul 3 21:51:47 UTC 2021 x86_64 Linux
Subsystem
No response
What steps will reproduce the bug?
I have created a simple HTTP proxy that pipes to a socket:
const http = require('http')
http.createServer((req, res) => {
const proxyReq = http.request({
host: null,
port: null,
socketPath: 'sock.sock',
path: req.url,
method: req.method,
headers: req.headers
}, (_res) => {
res.writeHead(_res.statusCode, _res.headers)
_res.pipe(res, { end: true })
})
req.pipe(proxyReq, { end: true })
}).listen(8080)
On v16.7.0
, this leads to an EPIPE
error after a few hundred requests. On v16.6.2
, it does not hit an EPIPE
error after many thousands of requests.
A full Docker Linux reproduction is here: https://github.com/mhassan1/node-16-7-0-proxy-epipe
How often does it reproduce? Is there a required condition?
It reproduces every time within a few hundred requests.
What is the expected behavior?
No EPIPE
.
What do you see instead?
EPIPE
after a few hundred requests:
node:events:371
throw er; // Unhandled 'error' event
^
Error: write EPIPE
at afterWriteDispatched (node:internal/stream_base_commons:164:15)
at writeGeneric (node:internal/stream_base_commons:155:3)
at Socket._writeGeneric (node:net:780:11)
at Socket._write (node:net:792:8)
at doWrite (node:internal/streams/writable:408:12)
at clearBuffer (node:internal/streams/writable:569:7)
at onwrite (node:internal/streams/writable:461:7)
at afterWriteDispatched (node:internal/stream_base_commons:167:9)
at writevGeneric (node:internal/stream_base_commons:147:3)
at Socket._writeGeneric (node:net:778:11)
Emitted 'error' event on ClientRequest instance at:
at Socket.socketErrorListener (node:_http_client:447:9)
at Socket.emit (node:events:394:28)
at emitErrorNT (node:internal/streams/destroy:157:8)
at emitErrorCloseNT (node:internal/streams/destroy:122:3)
at processTicksAndRejections (node:internal/process/task_queues:83:21) {
errno: -32,
code: 'EPIPE',
syscall: 'write'
}
Additional information
- This is a simplified reproduction of the same issue I am seeing when using http-proxy-middleware
- This does not reproduce on OS X
- This does not reproduce when proxying to a port
- This reproduces on
v14.18.0
but notv14.17.6
- This does not reproduce when the proxy and the backend are listening in the same Node process; they must be listening in different processes