If the client disconnects before the remote server, the entire server process can be killed by an unhandled I/O error.
The code in https://github.com/chimurai/http-proxy-middleware/blob/master/src/handlers.ts#L52 (defaultErrorHandler) does not catch I/O exceptions raised by res.end. If there's an error sending the response, the error is allowed to propagate to the top level event loop, which in recent versions of nodejs will exit the entire process.
This can occur if the client has disconnected, and then an error is received from the remote host.
Ideally this function would catch exceptions thrown by res.end. If the error is something uninteresting like EPIPE it shouldn't even log it.
Example error:
events.js:177
throw er; // Unhandled 'error' event
^
Error: This socket has been ended by the other party
at TLSSocket.writeAfterFIN [as write] (net.js:407:14)
at TLSSocket.Writable.end (_stream_writable.js:582:10)
at TLSSocket.Socket.end (net.js:534:31)
at ProxyServer.defaultErrorHandler (/home/ubuntu/app/node_modules/http-proxy-middleware/lib/handlers.js:76:7)
at ProxyServer.emit (/home/ubuntu/app/node_modules/eventemitter3/index.js:204:33)
at ClientRequest.onOutgoingError (/home/ubuntu/app/node_modules/http-proxy/lib/http-proxy/passes/ws-incoming.js:157:16)
at ClientRequest.emit (events.js:200:13)
at Socket.socketErrorListener (_http_client.js:402:9)
at Socket.emit (events.js:200:13)
at emitErrorNT (internal/streams/destroy.js:91:8)
at emitErrorAndCloseNT (internal/streams/destroy.js:59:3)
at processTicksAndRejections (internal/process/task_queues.js:84:9)
Emitted 'error' event at:
at emitErrorNT (net.js:1253:8)
at processTicksAndRejections (internal/process/task_queues.js:84:9) {
code: 'EPIPE'
}
(Write your steps here:)
Client disconnects should not cause the whole process to exit with error status, even if an I/O error is received from the remote server just afterwards.
Processes using the middleware occasionally abort with a stack trace and have to be restarted.
Configured using the proxy option to webpack-dev-server.
Thanks for reporting this issue.
Server should indeed not crash.
+1
Most helpful comment
+1