Ошибка 1006 websocket

I would like to get the reason websockets closed, so I can show the right message to the user. I have sok.onerror=function (evt) {//since there is an error, sockets will close so... sok.

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

@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

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

1000 CLOSE_NORMAL

1000 indicates a normal closure, meaning that the purpose for which the connection was established has been fulfilled.

1001 CLOSE_GOING_AWAY

1001 indicates that an endpoint is «going away», such as a server going down or a browser having navigated away from a page.

1002 CLOSE_PROTOCOL_ERROR

1002 indicates that an endpoint is terminating the connection due to a protocol error.

1003 CLOSE_UNSUPPORTED

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 CLOSED_NO_STATUS

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 CLOSE_ABNORMAL

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 CLOSE_TOO_LARGE

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

Понравилась статья? Поделить с друзьями:
  • Ошибка 1006 bigbluebutton как исправить
  • Ошибка 1005f mac os
  • Ошибка 10054 удаленный хост принудительно разорвал существующее подключение
  • Ошибка 10054 как исправить
  • Ошибка 10053 132