[BUG] uncaught error: RangeError: Invalid WebSocket frame: RSV1 must be clear

[pgerstbach]

Describe the bug
During the last couple of days my nostream implementation failed with an error multiple times.
I had to manually restart nostream.

When nostream crashes the following errors showed in the logs:

| uncaught error: RangeError: Invalid WebSocket frame: RSV1 must be clear
|     at Receiver.getInfo (/app/node_modules/ws/lib/receiver.js:199:14)
|     at Receiver.startLoop (/app/node_modules/ws/lib/receiver.js:146:22)
|     at Receiver._write (/app/node_modules/ws/lib/receiver.js:84:10)
|     at writeOrBuffer (node:internal/streams/writable:392:12)
|     at _write (node:internal/streams/writable:333:10)
|     at Writable.write (node:internal/streams/writable:337:10)
|     at Socket.socketOnData (/app/node_modules/ws/lib/websocket.js:1274:35)
|     at Socket.emit (node:events:513:28)
|     at addChunk (node:internal/streams/readable:324:12)
|     at readableAddChunk (node:internal/streams/readable:297:9) {
|   code: 'WS_ERR_UNEXPECTED_RSV_1',
|   [Symbol(status-code)]: 1002
| }

To Reproduce
I don't know how to reproduce it. But of course I am willing to help to track it down.

Expected behavior
No error :-)

System (please complete the following information):

• OS: Ubuntu 22.04.2
• Platform: docker
• Version: 1.22.06

Logs
No more logs before and after the stacktrace.

Additional context
Others seem to have the same problem:
#225 (comment)

[agthies2]

seeing this as well. Comes with these types of requests in nginx access.log:
125.195.62.32 - - [07/Mar/2023:10:14:35 +0000] "Version: 13\x0D\x0AS" 101 4 "-" "-"
106.154.136.233 - - [07/Mar/2023:00:33:08 +0000] "onnection: Upg" 101 4 "-" "-"
but also (less frequently) with the regular /GET

[pgerstbach]

Yes, I have the same lines always at the same time, there is an error.
It is always a HTTP 101 protocol switch with payload 4 bytes:

x.x.x.x - - [07/Mar/2023:13:55:07 +0100] "GET / HTTP/1.1" 101 4 "-" "-"

And I just found my own IP in the NGINX logs, while I was only running Damus at that time.
@jb55 Maybe you can help to track this down?

[pgerstbach]

I just tried to debug it with Damus in XCode: I was able to create this RSV1 error within nostream a few times, but I could not find out in which circumstances it happens. Sometimes it does, sometimes it does not. And it never resulted in crashing nostream, only those uncaught errors occurred. But when it happens, it happens directly after Damus calls socket.connect() in RelayConnection:53.

Sorry not to be more precise, I have never used XCode before, still learning.

[cameri]

I just tried to debug it with Damus in XCode: I was able to create this RSV1 error within nostream a few times, but I could not find out in which circumstances it happens. Sometimes it does, sometimes it does not. And it never resulted in crashing nostream, only those uncaught errors occurred. But when it happens, it happens directly after Damus calls socket.connect() in RelayConnection:53.

Sorry not to be more precise, I have never used XCode before, still learning.

Amazing. Are there any options passed to that socket or socket.connect function? According to the node ws library this error occurs when the client and server negotiate ws extensions, the server lets the client know it doesn't support compression but the client sends compressed frames anyways

[pgerstbach]

The socket is created using the following line:
let socket = WebSocket(request: req, compressionHandler: .none)
https://github.com/damus-io/damus/blob/795577a0a1065dee1ba74040f9ce109d659f1826/damus/Nostr/RelayConnection.swift#L24

I have never programmed Swift, but "compressionHandler: .none" indicates no compression to me!

[zyklopisch]

Can also confirm this - using latest version of nostream and getting this error on my VPS all the time - although it does not seem to has a severe impact? Relay runs smooth so far I can see....

[pgerstbach]

My nostream deployment crashes often - if I don't do a daily restart. But honestly I don't know if this error causes the crashing. Although this error is the only I see in the logs. But that does not necessarily mean the two are connected.