4

I'm using http-proxy-middleware to proxy some API endpoints to my Create React App development server.

I recently introduced a WebSocket endpoint, and I'm proxying it with the following code in setupProxy.js:

const proxy = require('http-proxy-middleware');

const target = 'http://localhost:8000';

module.exports = function(app) {
  [...] // other proxies for HTTP endpoints
  app.use(proxy('/api/ws', { ws: true, target }));
};

The problem I'm having is that if I restart the backend, and the WebSocket connection is interrupted, the whole development server crashes with:

[HPM] Upgrading to WebSocket
events.js:170
      throw er; // Unhandled 'error' event
      ^

Error: read ECONNRESET
    at TCP.onStreamRead (internal/stream_base_commons.js:171:27)
Emitted 'error' event at:
    at emitErrorNT (internal/streams/destroy.js:91:8)
    at emitErrorAndCloseNT (internal/streams/destroy.js:59:3)
    at processTicksAndRejections (internal/process/task_queues.js:81:17)
error Command failed with exit code 1.

I was wondering how could I gracefully handle errors in the WebSocket proxy so that the server won't crash, but will wait for the WebSocket to be available again instead?

Fez Vrasta
  • 14,110
  • 21
  • 98
  • 160
  • Did you mean, your WebSocket is trying to connect to the target before it is up? – shubhambharti201 Nov 29 '19 at 08:59
  • The WebSocket server is up, the express server goes up, it finds the WebSocket, everything okay. Then, suddenly, the WebSocket server is restarted, I get the error. – Fez Vrasta Nov 29 '19 at 12:26
  • What version of node do you use? Can you post your `package-lock.json`? – user3840170 Nov 30 '19 at 03:46
  • It's node 11.15.0, I can't post the lock file unfortunately, but I'm pretty sure it's not a version issue, it's just that the moment when the socket is disconnected I should handle the error somehow. – Fez Vrasta Nov 30 '19 at 10:25
  • Well, I cannot reproduce this problem on node v13.0.0, `express` 4.17.1, `http-proxy` 1.18.0, `http-proxy-middleware` 0.20.0. The proxy logs the `ECONNRESET` in the console and keeps running. Maybe in fact you *should* treat it as a bug in (one of) the libraries. – user3840170 Nov 30 '19 at 18:16
  • @user3840170 I suppose it's an issue specifically with create-react-app development server – Fez Vrasta Dec 02 '19 at 14:04

2 Answers2

2

This issue does not reproduce with current versions of the relevant packages and was probably caused by an outdated, buggy dependency; without the asker's lockfile it's probably not feasible to investigate which dependency it was. With the package versions listed below, the proxy server does not crash, but instead logs the error and continues running. This behaviour is enabled in src/http-proxy-middleware.ts, which may be of interest for someone who wishes to enable custom error handling.

Summary of package-lock.json where crashing is not observed:

accepts: 1.3.7
array-flatten: 1.1.1
async-limiter: 1.0.1
body-parser: 1.19.0
braces: 3.0.2
bytes: 3.1.0
content-disposition: 0.5.3
content-type: 1.0.4
cookie: 0.4.0
cookie-signature: 1.0.6
debug: 3.2.6
depd: 1.1.2
destroy: 1.0.4
ee-first: 1.1.1
encodeurl: 1.0.2
escape-html: 1.0.3
etag: 1.8.1
eventemitter3: 4.0.0
express: 4.17.1
fill-range: 7.0.1
finalhandler: 1.1.2
follow-redirects: 1.9.0
forwarded: 0.1.2
fresh: 0.5.2
http-errors: 1.7.2
http-proxy: 1.18.0
http-proxy-middleware: 0.20.0
iconv-lite: 0.4.24
inherits: 2.0.3
ipaddr.js: 1.9.0
is-extglob: 2.1.1
is-glob: 4.0.1
is-number: 7.0.0
lodash: 4.17.15
media-typer: 0.3.0
merge-descriptors: 1.0.1
methods: 1.1.2
micromatch: 4.0.2
mime: 1.6.0
mime-db: 1.42.0
mime-types: 2.1.25
ms: 2.1.2
negotiator: 0.6.2
on-finished: 2.3.0
parseurl: 1.3.3
path-to-regexp: 0.1.7
picomatch: 2.1.1
proxy-addr: 2.0.5
qs: 6.7.0
range-parser: 1.2.1
raw-body: 2.4.0
requires-port: 1.0.0
safe-buffer: 5.1.2
safer-buffer: 2.1.2
send: 0.17.1
serve-static: 1.14.1
setprototypeof: 1.1.1
statuses: 1.5.0
to-regex-range: 5.0.1
toidentifier: 1.0.0
type-is: 1.6.18
unpipe: 1.0.0
utils-merge: 1.0.1
vary: 1.1.2
ws: 7.2.0

user3840170
  • 26,597
  • 4
  • 30
  • 62
0

I've had the same problem. Just upgrading http-proxy-middleware to 0.20.0 did the trick

bezdonas
  • 13
  • 2