简体   繁体   中英

Handle WebSocket error with http-proxy-middleware

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?

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

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

The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM