Thought this might be handy for others. Knowing regex is useful, kids. Stay in school.
Edit: Turned it into a handy dandy function!
let specificStatusCodeMappings = {
'1000': 'Normal Closure',
'1001': 'Going Away',
'1002': 'Protocol Error',
'1003': 'Unsupported Data',
'1004': '(For future)',
'1005': 'No Status Received',
'1006': 'Abnormal Closure',
'1007': 'Invalid frame payload data',
'1008': 'Policy Violation',
'1009': 'Message too big',
'1010': 'Missing Extension',
'1011': 'Internal Error',
'1012': 'Service Restart',
'1013': 'Try Again Later',
'1014': 'Bad Gateway',
'1015': 'TLS Handshake'
};
function getStatusCodeString(code) {
if (code >= 0 && code <= 999) {
return '(Unused)';
} else if (code >= 1016) {
if (code <= 1999) {
return '(For WebSocket standard)';
} else if (code <= 2999) {
return '(For WebSocket extensions)';
} else if (code <= 3999) {
return '(For libraries and frameworks)';
} else if (code <= 4999) {
return '(For applications)';
}
}
if (typeof(specificStatusCodeMappings[code]) !== 'undefined') {
return specificStatusCodeMappings[code];
}
return '(Unknown)';
}
Usage:
getStatusCodeString(1006); //'Abnormal Closure'
{
'0-999': '(Unused)',
'1016-1999': '(For WebSocket standard)',
'2000-2999': '(For WebSocket extensions)',
'3000-3999': '(For libraries and frameworks)',
'4000-4999': '(For applications)'
}
{
'1000': 'Normal Closure',
'1001': 'Going Away',
'1002': 'Protocol Error',
'1003': 'Unsupported Data',
'1004': '(For future)',
'1005': 'No Status Received',
'1006': 'Abnormal Closure',
'1007': 'Invalid frame payload data',
'1008': 'Policy Violation',
'1009': 'Message too big',
'1010': 'Missing Extension',
'1011': 'Internal Error',
'1012': 'Service Restart',
'1013': 'Try Again Later',
'1014': 'Bad Gateway',
'1015': 'TLS Handshake'
}
Source (with minor edits for terseness): https://developer.mozilla.org/en-US/docs/Web/API/CloseEvent#Status_codes
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
Closed
Esqarrouth opened this issue
Feb 27, 2019
· 7 comments
Comments
- I’ve searched for any related issues and avoided creating a duplicate
issue.
Description
I’m logging disconnects in my web game. It seems 75% of the sessions are getting disconnected with the code 1001 (normal) and 25% are getting disconnected with the code 1006 (error). https://tools.ietf.org/html/rfc6455
Sometimes on the error reason I see this text:
CloudFlare WebSocket Proxy restarting
But he majority of 1006 disconnects don’t give any reason at all. The players just disconnect with no reason at all. This usually happens at 5-30 minutes mark while the player is actively playing the game.
The setup I’m has these:
- Node.js
- Express.js
- Cloudflare
- Digital Ocean
- Docker
- https://github.com/websockets/ws
- SSL
- Nginx timeout = 3600s
- Ping/Pong isAlive = 30s
My question is:
- How can I debug this problem better?
- What are common cases which might be causing this problem?
Reproducible in:
- version: 3.3.1
- Node.js version(s): v10.11.0
- OS version(s): Docker 18.09.0
Also posted in: https://stackoverflow.com/questions/54909597/websocket-disconnects-with-1006-error-without-a-reason
- How can I debug this problem better?
There is not much you can do about it because it’s not an issue. It’s a condition you have to deal with.
- What are common cases which might be causing this problem?
A close frame is not received, likely because it was not sent.
Nvm, the 3.x release line should not be affected by that but it doesn’t harm anyway to update, if you can.
Copy link
Contributor
Author
I’m tracking the disconnections used ws 3.3.1 until 3 March then updated ws to 6.1.4. I am adding the charts.
Conclusion:
- Updating to 6.1.4 did not solve the disconnect problems.
- It hasn’t seem to make any changes in terms of general disconnections. (Volume of 1001 could be ignored because it is largely dependent on the traffic that day)
- 1000 errors completely disappeared after updating and 1005 errors started showing up, while previously we didn’t have these. (I hope this is the expected behaviour?)
I hope this is the expected behaviour?
Yes, 1005 is a close frame with an empty payload.
Copy link
Contributor
Author
- How can I debug this problem better?
There is not much you can do about it because it’s not an issue. It’s a condition you have to deal with.
- You mean it is not an issue with ws, right?
- What do you mean there is not much you can do about it?
- What do you mean it’s a condition you have to deal with? If it is common, how do you or other people generally deal with this issue?
- What are common cases which might be causing this problem?
A close frame is not received, likely because it was not sent.
- Do you mean that socket server didn’t send the close frame to client?
- You mean it is not an issue with ws, right?
Yes, I’m not aware of ws dropping close frames.
- What do you mean there is not much you can do about it?
It’s outside of your control. You can’t force the client to send a close frame. If this is coming from a browser try to call ws.close()
before the page unload and see if it makes any difference.
- What do you mean it’s a condition you have to deal with? If it is common, how do you or other people generally deal with this issue?
Treat it for what it is. An «abnormal» closure.
- Do you mean that socket server didn’t send the close frame to client?
The client.
2 participants
Summary
- TL;DR
- What is the websocket 1006 error?
- Why do I see this error?
- How to fix it?
- Use the –link parameter to get a temporary https
- Option 1 : get the link locally
- Option 2 : Use ngrok
- Use the –link parameter to get a temporary https
At the end of the installation of the code server, you are ready to enjoy your new development workflow, and then, you see this message “WebSocket close with status code 1006”. How to solve it? Check out these answers
Note: If you are confused about what code server is, check this post which explains it.
TL;DR
Check your https
connection. Your browser cannot reach your code server instance.
What is the websocket 1006 error?
The websocket 1006 error means that the connection has been closed, locally, by your browser.
If you see a close code 1006, you have a very low level error with WebSocket itself as this error is not really meant for the user. The websocket 1006 error points to a low level issue with your code and implementation.
Why do I see this error?
The main reason is that the connection was closed abnormally (locally) by the browser implementation.
It means that your browser cannot reach your remote code server.
The main issue is about your https
connection to the server.
How to fix it?
You might not be sure about the process to follow in order to setup code server. I did a tutorial on how to setup code server cloud IDE platform on digitalocean using kubernetes.
If you speak french, the french version is here.
The good news is that, there are two possible solutions :
Use the –link parameter to get a temporary https
Option 1 : get the link locally
code-server --host 127.0.0.1 --bind-addr 0.0.0.0:9000 --auth password --link
Option 2 : Use ngrok
ngrok will tunnel and create an https connection to your server.
code-server --host 127.0.0.1 --bind-addr 0.0.0.0:9000 --auth password ngrok http 9000
Use wss to forward
Here is the code to perform the forwarding and solve the issue
// forward websocket (wss -> ws)
httpsServer.on('upgrade', function (req, socket, head) {
proxy.ws(req, socket, head, {
target: 'ws://...',
ws: true
})
})
1000 1000 indicates a normal closure, meaning that the purpose for which the connection was established has been fulfilled. |
1001 1001 indicates that an endpoint is «going away», such as a server going down or a browser having navigated away from a page. |
1002 1002 indicates that an endpoint is terminating the connection due to a protocol error. |
1003 1003 indicates that an endpoint is terminating the connection because it has received a type of data it cannot accept (e.g., an endpoint that understands only text data MAY send this if it receives a binary message). |
1004 Reserved. The specific meaning might be defined in the future. |
1005 1005 is a reserved value and MUST NOT be set as a status code in a Close control frame by an endpoint. It is designated for use in applications expecting a status code to indicate that no status code was actually present. |
1006 1006 is a reserved value and MUST NOT be set as a status code in a Close control frame by an endpoint. It is designated for use in applications expecting a status code to indicate that the connection was closed abnormally, e.g., without sending or receiving a Close control frame. |
1007 Unsupported payload 1007 indicates that an endpoint is terminating the connection because it has received data within a message that was not consistent with the type of the message (e.g., non-UTF-8 [RFC3629] data within a text message). |
1008 Policy violation 1008 indicates that an endpoint is terminating the connection because it has received a message that violates its policy. This is a generic status code that can be returned when there is no other more suitable status code (e.g., 1003 or 1009) or if there is a need to hide specific details about the policy. |
1009 1009 indicates that an endpoint is terminating the connection because it has received a message that is too big for it to process. |
1010 Mandatory extension 1010 indicates that an endpoint (client) is terminating the connection because it has expected the server to negotiate one or more extension, but the server didn’t return them in the response message of the WebSocket handshake. The list of extensions that are needed SHOULD appear in the /reason/ part of the Close frame. Note that this status code is not used by the server, because it can fail the WebSocket handshake instead. |
1011 Server error 1011 indicates that a server is terminating the connection because it encountered an unexpected condition that prevented it from fulfilling the request. |
1012 Service restart 1012 indicates that the server / service is restarting. |
1013 Try again later 1013 indicates that a temporary server condition forced blocking the client’s request. |
1014 Bad gateway 1014 indicates that the server acting as gateway received an invalid response |
1015 TLS handshake fail 1015 is a reserved value and MUST NOT be set as a status code in a Close control frame by an endpoint. It is designated for use in applications expecting a status code to indicate that the connection was closed due to a failure to perform a TLS handshake (e.g., the server certificate can’t be verified). |