ERROR Invalid WebSocket frame: invalid status code 22373

[arpowers]

• [x ] I've searched for any related issues and avoided creating a duplicate
  issue.

Description

This appears to be a new issue that is creeping up due to a change somewhere. There are only a few mentions of this code 22373 across the internet but it's been in the last month or so. To me this suggests are recent changes somewhere related to websockets.

The error is ERROR Invalid WebSocket frame: invalid status code 22373

This error has been completely crashing our analytics server whenever it occurs. Would suggest that WS has a way to catch errors like this as we are likely having data loss because of it.

Reproducible in:

• version: latest
• Node.js version(s): 14
• OS version(s): latest

Steps to reproduce:

1. Unsure how to reproduce a socket frame with this error code

[lpinca]

Duplicate of #1916?

[arpowers]

@lpinca yes, the same problem. I didn't see that issue as it was closed.

Not sure where the status code is coming from, but whatever the case, I'd assume it shouldn't be crashing our entire ingest server?

Also, I can't figure out how to catch this error. I tried what you suggested in that post and it doesn't seem to work. I am using a bit of async/await but have a pretty typical ws implementation.

[lpinca]

Not sure where the status code is coming from, but whatever the case, I'd assume it shouldn't be crashing our entire ingest server?

Did you see #1916 (comment)? That example triggers the error and the server does not crash. Make sure you have a listener for 'error' event and that it is not removed until the 'close' event is emitted.

[lpinca]

Are you removing the 'error' listener sometime during the lifetime of the WebSocket object?

[arpowers]

@lpinca thanks for the follow up, i followed your guide and redeployed last night. It might be working actually, no crashes over night.

Getting errors caught like this one (is that the same issue?)

[lpinca]

Yes. That is not the same error but it is still caused by an invalid frame.

[ltm]

FWIW, we've noticed Safari on iOS 15 beta (Version/15.0 Mobile/15E148 Safari/604.1) send an invalid close frame. The frame is missing the two-byte status code, so the first two bytes of the body ("WebSocket is closed...") are interpreted as the status code: 'We' == 0x5765 == 22373.

[arpowers]

@ltm INTERESTING. Great work!

well for posterity there is the cause of the issue, this is the first time it's been documented in a discoverable way...

@lpinca thank you as well for this rock solid piece of software

[matthewp]

Hi everyone, I've been able to replicate this issue specifically when using the NSURLSession WebSocket feature of Safari. If you go to Develop -> Experimental Features and select NSURLSession WebSocket you should see this error.

It sounds like maybe this a bug in Safari then?

[Esqarrouth]

Are you removing the 'error' listener sometime during the lifetime of the WebSocket object?

#1611 (comment)

Any input in this? The error listener was always there for years, it caught a lot of errors, but this specific 22373 one crashed the whole server

[lpinca]

@goktugyil see #1916 (comment). You can open a connection and send that frame to reproduce. It is like any other "invalid frame" error.

[dhillon-lovey3110]

RangeError: Invalid WebSocket frame: invalid status code 60015
at Receiver.controlMessage (/node_modules/ws/lib/receiver.js:561:18)
at Receiver.getData (/node_modules/ws/lib/receiver.js:429:42)
at Receiver.startLoop (/node_modules/ws/lib/receiver.js:148:22)
at Receiver._write (/node_modules/ws/lib/receiver.js:83:10)
at writeOrBuffer (internal/streams/writable.js:358:12)
at Receiver.Writable.write (internal/streams/writable.js:303:10)
at TLSSocket.socketOnData (/node_modules/ws/lib/websocket.js:1263:35)
at TLSSocket.emit (events.js:400:28)
at TLSSocket.emit (domain.js:475:12)
at addChunk (internal/streams/readable.js:293:12) {
code: 'WS_ERR_INVALID_CLOSE_CODE',
[Symbol(status-code)]: 1002

crashing on this, any ideas ?

[daixianceng]

@dhillon-lovey3110 Did you solve it? I am now stuck with the error of "60015"

[RenatoExpert]

@dhillon-lovey3110 Did you solve it? I am now stuck with the error of "60015"

I have the same problem :(

[codeedog]

I solved this when I was having this problem with Angular 15, Node 18, Webpack Dev Server 4.11.1.

Match the URL for WebSocket to the proxy configuration file. DO NOT USE use the top level /. In my example below, I used /pipe although it also worked with /api for a ws:// target.

// Browser JavaScript snippet
const socket$ = new WebSocketSubject<Message>("ws://localhost:4200/pipe");

# proxy.conf.json
{
  "/api": {
    "target": "http://localhost:3000",
    "secure": false
  },
  "/pipe": {
    "target": "ws://localhost:3000",
    "secure": false,
    "ws": true,
    "logLevel": "debug"
  }
}

Below config which didn't work with Angular 15, Webpack Dev Server 4.11.1, but did work in my prior Angular 12, Webpack Dev Server 3.11.3 configuration. It was failing in upgrade and I had no idea why until I beat my head against the wall, the desk, the keyboard, ... and somehow tripped upon the above configuration.

*** DOES NOT WORK ***
// Browser JavaScript snippet
const socket$ = new WebSocketSubject<Message>("ws://localhost:4200/");

# proxy.conf.json
{
  "/api": ...,
  "/": {
    "target": "ws://localhost:3000",
    ...
  }
}

Finally, in my shell I ran npm ls http-proxy-middleware to find out which version of Webpack Dev Server I was running under each configuration (Angular 15, Angular 12). I've also included the results of the run.

For Angular 15:

> npm ls http-proxy-middleware
project@0.2.0 /Users/codeedog/src/project
├─┬ @angular-devkit/build-angular@15.0.3
│ └─┬ webpack-dev-server@4.11.1
│   └── http-proxy-middleware@2.0.6
└─┬ @nrwl/angular@15.3.0
  └─┬ @nguniversal/builders@15.0.0
    └── http-proxy-middleware@2.0.6 deduped

For Angular 12:

npm ls http-proxy-middleware
project@0.1.0 /Users/codeedog/src/project
└─┬ @angular-devkit/build-angular@12.2.18
  └─┬ webpack-dev-server@3.11.3
    └── http-proxy-middleware@0.19.1 

Incidentally, I found similar issues on GitHub http-proxy-middleware #476 and angular-cli #23155 when searching for this error code. Perhaps, this also helps in those.