-
Notifications
You must be signed in to change notification settings - Fork 207
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[BUG] ws/lib/sender.js:162: 'First argument must be a valid error code number' #465
Labels
bug
Something isn't working
Comments
mrbbot
added a commit
that referenced
this issue
Feb 7, 2023
See #490 for a detailed description of the problem this solves. Previously, we had `ws`'s automatic `Sec-WebSocket-Protocol` handling enabled, in addition to adding the header ourselves. This lead to duplicate sub-protocols in the WebSocket handshake response which is a protocol error. Workers require users to include this header themselves in WebSocket `Response`s, so ignoring this key outright when copying headers would be incorrect. Instead, we just disable `ws`'s automatic handling. Funnily enough, we had exactly the same issue in Miniflare 2 too (#179), and fixed it in 34cc73a. Looks like the fix didn't make it into Miniflare 3 though. :( This PR also fixes an issue where `1006` closures were not propagated correctly. This is an issue in Miniflare 2 too (#465), so we should back-port this. Supersedes #490
mrbbot
added a commit
that referenced
this issue
Feb 7, 2023
Previously, the abnormal closure close code `1006` was passed directly to `StandardWebSocket#close()`. This is forbidden, throwing an uncatchable validation error. With this change, the WebSocket is `terminate()`ed instead, propagating the `1006` code correctly to the other side of the connection. Ref #493
mrbbot
added a commit
that referenced
this issue
Feb 9, 2023
See #490 for a detailed description of the problem this solves. Previously, we had `ws`'s automatic `Sec-WebSocket-Protocol` handling enabled, in addition to adding the header ourselves. This lead to duplicate sub-protocols in the WebSocket handshake response which is a protocol error. Workers require users to include this header themselves in WebSocket `Response`s, so ignoring this key outright when copying headers would be incorrect. Instead, we just disable `ws`'s automatic handling. Funnily enough, we had exactly the same issue in Miniflare 2 too (#179), and fixed it in 34cc73a. Looks like the fix didn't make it into Miniflare 3 though. :( This PR also fixes an issue where `1006` closures were not propagated correctly. This is an issue in Miniflare 2 too (#465), so we should back-port this. Supersedes #490
mrbbot
added a commit
that referenced
this issue
Feb 9, 2023
Previously, the abnormal closure close code `1006` was passed directly to `StandardWebSocket#close()`. This is forbidden, throwing an uncatchable validation error. With this change, the WebSocket is `terminate()`ed instead, propagating the `1006` code correctly to the other side of the connection. Ref #493
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
miniflare occasionally throws like this, see cloudflare/workers-sdk#2476 or cloudflare/workers-sdk#1749,
or here #284 .
The problem comes here
miniflare/packages/web-sockets/src/couple.ts
Lines 57 to 63 in 80046ce
and for ws, it receives:
Maybe it just needs some tweaks to fit in.
The text was updated successfully, but these errors were encountered: