Websocket ошибка 1006

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

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

@Esqarrouth

  • 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:

  1. How can I debug this problem better?
  2. 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

@lpinca

  1. 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.

  1. What are common cases which might be causing this problem?

A close frame is not received, likely because it was not sent.

@lpinca

@lpinca

Nvm, the 3.x release line should not be affected by that but it doesn’t harm anyway to update, if you can.

@Esqarrouth



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?)

21
23

@lpinca

I hope this is the expected behaviour?

Yes, 1005 is a close frame with an empty payload.

@Esqarrouth



Copy link


Contributor


Author

  1. 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.

  1. You mean it is not an issue with ws, right?
  2. What do you mean there is not much you can do about it?
  3. 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?
  1. What are common cases which might be causing this problem?

A close frame is not received, likely because it was not sent.

  1. Do you mean that socket server didn’t send the close frame to client?

@lpinca

  1. You mean it is not an issue with ws, right?

Yes, I’m not aware of ws dropping close frames.

  1. 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.

  1. 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.

  1. Do you mean that socket server didn’t send the close frame to client?

The client.

2 participants

@lpinca

@Esqarrouth

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?

Понравилась статья? Поделить с друзьями:
  • Webrequest cannot resolve destination host duskwood ошибка
  • Webasto multicontrol ошибка tea
  • Webpack cli ошибка
  • Webmoney ошибка 2560
  • Webasto h4e ошибка