Node-http-proxy: ERR_STREAM_WRITE_AFTER_END write after end

Created on 23 May 2019  路  4Comments  路  Source: http-party/node-http-proxy

I often get the following error when I run tests through cypress.
I suppose that connections from the browser are reseted and so the socket is closed.

error: write after end {"name":"Error [ERR_STREAM_WRITE_AFTER_END]","stack":"Error [ERR_STREAM_WRITE_AFTER_END]: write after end
    at writeAfterEnd (_stream_writable.js:243:12)
    at Socket.Writable.write (_stream_writable.js:291:5)
    at ClientRequest.<anonymous> (/app/node_modules/http-proxy/lib/http-proxy/passes/ws-incoming.js:115:16)
    at ClientRequest.emit (events.js:182:13)
    at ClientRequest.EventEmitter.emit (domain.js:442:20)
    at HTTPParser.parserOnIncomingClient [as onIncoming] (_http_client.js:555:21)
    at HTTPParser.parserOnHeadersComplete (_http_common.js:109:17)
    at Socket.socketOnData (_http_client.js:441:20)
    at Socket.emit (events.js:182:13)
    at Socket.EventEmitter.emit (domain.js:442:20)","code":"ERR_STREAM_WRITE_AFTER_END"}

Testing if socket is open in ws-incoming.js seems to solve the issue

    proxyReq.on('response', function (res) {
      // if upgrade event isn't going to happen, close the socket
      if (!res.upgrade && socket.readyState === socket.OPEN) {
        socket.write(createHttpHeader('HTTP/' + res.httpVersion + ' ' + res.statusCode + ' ' + res.statusMessage, res.headers));
        res.pipe(socket);
      }
    });

Is it the right way to solve the issue ?

Most helpful comment

Is @caosm's solution the correct one and if yes, could that be merged?

Is there a way of achieving that same workaround without patching the library?

I am having the same issue as @xumix

All 4 comments

Got the same issue with Firefox, signalr, CRA and proxy-middleware.

`-- [email protected]
  `-- [email protected]

I've configured my proxy like this:

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

module.exports = function(app) {
    app.use(proxy("/cms",
        {
            target: "http://localhost:91",
            changeOrigin: true, // needed for virtual hosted sites
            ws: true, // proxy websockets
            pathRewrite: {
                "^/cms": "/"
            }
        }));
};

Every time when signalr sends a request the started app crashes with this error:

events.js:167
      throw er; // Unhandled 'error' event
      ^

Error [ERR_STREAM_WRITE_AFTER_END]: write after end
    at writeAfterEnd (_stream_writable.js:243:12)
    at Socket.Writable.write (_stream_writable.js:291:5)
    at ClientRequest.<anonymous> (c:\Projects\Pp2\source\Pp\Front\Pp3.Web\ClientApp\node_modules\http-proxy\lib\http-proxy\passes\ws-incoming.js:115:16)
    at ClientRequest.emit (events.js:182:13)
    at HTTPParser.parserOnIncomingClient [as onIncoming] (_http_client.js:555:21)
    at HTTPParser.parserOnHeadersComplete (_http_common.js:109:17)
    at Socket.socketOnData (_http_client.js:441:20)
    at Socket.emit (events.js:182:13)
    at addChunk (_stream_readable.js:283:12)
    at readableAddChunk (_stream_readable.js:264:11)
    at Socket.Readable.push (_stream_readable.js:219:10)
    at TCP.onStreamRead [as onread] (internal/stream_base_commons.js:94:17)
Emitted 'error' event at:
    at writeAfterEnd (_stream_writable.js:245:10)
    at Socket.Writable.write (_stream_writable.js:291:5)
    [... lines matching original stack trace ...]
    at TCP.onStreamRead [as onread] (internal/stream_base_commons.js:94:17)

Any news?
This is really annoying, my development server crashes every several minutes because of this bug.

Testing if socket is open in ws-incoming.js seems to solve the issue

    proxyReq.on('response', function (res) {
      // if upgrade event isn't going to happen, close the socket
      if (!res.upgrade && socket.readyState === socket.OPEN) {
        socket.write(createHttpHeader('HTTP/' + res.httpVersion + ' ' + res.statusCode + ' ' + res.statusMessage, res.headers));
        res.pipe(socket);
      }
    });

Is it the right way to solve the issue ?

this way solved my problem, and has been running normally in prodution for several months

Is @caosm's solution the correct one and if yes, could that be merged?

Is there a way of achieving that same workaround without patching the library?

I am having the same issue as @xumix

Was this page helpful?
0 / 5 - 0 ratings

Related issues

karthikus picture karthikus  路  3Comments

isawk picture isawk  路  5Comments

lgzhang picture lgzhang  路  4Comments

catamphetamine picture catamphetamine  路  6Comments

SET001 picture SET001  路  5Comments