proxy to localhost ws/WebSocketServer results in Error: RSV1 must be clear

Expected behavior

Proxying to the locally running WebSocketServer on a different port succeeds.

Actual behavior

Proxying to the locally running WebSocketServer on a different port fails with an error of; Error: RSV1 must be clear. This is internally thrown by ws because the buffer that the server is receiving begins with bytes that are technically invalid. See below for triage.

Setup

• http-proxy-middleware: 0.17.4
• server: express@latest
• express: latest
• ws: latest

proxy middleware configuration

const wsProxy = proxy('/', {
  target: 'http://localhost:9090',
  ws: true,
  logLevel: 'debug'
});

server mounting

const express = require('express')
const proxy = require('http-proxy-middleware');
const WebSocket = require('ws');

const wsProxy = proxy('/', {
  target: 'http://localhost:9090',
  ws: true,
  logLevel: 'debug'
});

const wss = new WebSocket.Server({ port: 9090 });

wss.on('connection', (socket) => {
  console.log('socket server connected');
  socket.on('message', (message) => {
    console.log('socket server message:', message);
    socket.send(`response: ${message}`);
  });
});

const app = express();
app.use('/', express.static(__dirname));
app.use(wsProxy);

const server = app.listen(8080, () => {

  const internalWss = new WebSocket.Server({ server });

  const client = new WebSocket('ws://localhost:8080');

  client.on('message', (message) => {
    console.log('client message:', message);
  });

  client.on('open', () => {
    console.log('client open');
    client.send('challenge');
  });
});

server.on('upgrade', wsProxy.upgrade);

This code block reproduces the issue with 100% of test runs locally here. If you comment out the line;

const internalWss = new WebSocket.Server({ server });

then the example runs successfully without error. There’s some kind of caveat/edge case with there being a WebSocketServer connected to the server on port 8080, as well as bound to localhost:9090. I did attempt to work my way through the http-proxy-middleware source to debug the cause but I came up empty. I also spent a fair amount of time within the source for ws to make sure that it wasn’t an error there; in which I couldn’t pinpoint a cause either. Given that the addition/removal of the WebSocketServer on port 8080 (same as the server) caused failure/pass, I figured I’d start with an issue here.

[chimurai]

Thanks for the detailed report @shellscape. I’ll have to spend some time investigating this.

[shellscape]

@chimurai interesting. I wonder though if that setTimeout setup only succeeded without error because the internalWss wasn’t yet created and listening when the client message was sent.