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
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
})
})
You may get into a related type of issue where [[2022-01-02-how-does-code-server-works.md|code-server c]]omplains about the bindings file. The solution is in this blog post about solving binding file not found error.
Also, kubernetes and minikube are great choices to host code server.
Ubuntu 16.04, стек LAMP, для работы с websocket использую библиотеку workerman. Порт открыт в firewall (ufw). Соединение устанавливается корректно, сообщения отправляются, но при попытке чистого закрытия соединения через close как со стороны js так и со стороны сервера соединение у клиента закрывается с ошибкой 1006, без других подробностей. Еще на сервере установлен OpenVpn, но на другом порту. Есть какие-то идеи что это может быть и возможно какие-то шаги для дополнительной отладки чтобы конкретизировать/выяснить причину?
-
Вопрос задан
-
9236 просмотров
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
I’m using Redis + Webdis on Debian 7 32.
My issue is that all websocket connections are closed with the exit code 1006 after completing the first command (except the «SUBSCRIBE» one). For example, for this testJSON() function
function testJSON() {
var jsonSocket = new WebSocket("ws://ip:7379/.json");
jsonSocket.onopen = function() {
console.log("JSON socket connected!");
jsonSocket.send(JSON.stringify(["SET", "hello", "world"]));
jsonSocket.send(JSON.stringify(["GET", "hello"]));
};
jsonSocket.onmessage = function(messageEvent) {
console.log("JSON received:", messageEvent.data);
};
jsonSocket.onclose = function(messageEvent) {
//some logging
};
jsonSocket.onerror = function(messageEvent) {
//some logging
};
}
testJSON();
i’m getting (in Firebug)
JSON socket connected!
JSON received: {"SET":[true,"OK"]}
onClose: error.code 1006
The onError event is’nt working, and after the {«SET»:[true,»OK»]} response my connection closes. GET command is’nt working too. Same behavior in Firefox and Chrome. I checked the headers, it seems they are valid.
Any suggestions?