Websocket коды ошибок

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

0 — 999 Yes No Unused 1000 CLOSE_NORMAL No No Successful operation / regular socket shutdown 1001 CLOSE_GOING_AWAY No No Client is leaving (browser tab closing) 1002 CLOSE_PROTOCOL_ERROR Yes No Endpoint received a malformed frame 1003 CLOSE_UNSUPPORTED Yes No Endpoint received an unsupported frame (e.g. binary-only endpoint received text frame) 1004 Yes No Reserved 1005 CLOSED_NO_STATUS Yes No Expected close status, received none 1006 CLOSE_ABNORMAL Yes No No close code frame has been receieved 1007 Unsupported payload Yes No Endpoint received inconsistent message (e.g. malformed UTF-8) 1008 Policy violation No No Generic code used for situations other than 1003 and 1009 1009 CLOSE_TOO_LARGE No No Endpoint won’t process large frame 1010 Mandatory extension No No Client wanted an extension which server did not negotiate 1011 Server error No No Internal server error while operating 1012 Service restart No No Server/service is restarting 1013 Try again later No No Temporary server condition forced blocking client’s request 1014 Bad gateway No No Server acting as gateway received an invalid response 1015 TLS handshake fail Yes No Transport Layer Security handshake failure 1016 — 1999 Yes No Reserved for later 2000 — 2999 Yes Yes Reserved for websocket extensions 3000 — 3999 No Yes Registered first come first serve at IANA 4000 — 4999 No Yes Available for applications

WebSockets are a protocol that allows for real-time communication between a client and a server. The protocol enables bidirectional communication, meaning that both the client and server can send and receive data at any time. One of the critical components of the WebSocket protocol is the status codes. In this article, we will delve into WebSockets 101 status codes, what they signify, and how to handle them.

What are WebSockets?

WebSockets are a technology that allows for real-time communication between a client and a server. Unlike traditional HTTP requests that follow a request-response pattern, WebSockets enable bidirectional communication, meaning that both the client and server can send and receive data at any time.

WebSockets are ideal for applications that require real-time updates, such as chat applications, online games, and financial trading platforms. Additionally, WebSocket connections are persistent, meaning that the connection remains open until either the client or server decides to close it.

WebSockets 101 Status Codes

WebSockets 101 status codes are an essential part of the WebSocket protocol. They indicate the state of the WebSocket connection and provide information on any errors that may occur during the connection.

There are several WebSocket 101 status codes, and each code has a specific meaning. Some of the most common WebSocket 101 status codes include:

101 Switching Protocols

The 101 Switching Protocols status code indicates that the WebSocket handshake was successful, and the connection has been upgraded to the WebSocket protocol. This status code is the first message sent by the server to the client after a successful WebSocket handshake.

1006 Abnormal Closure

The 1006 Abnormal Closure status code indicates that the WebSocket connection was closed abnormally. This status code is usually sent by the server to the client when the server encounters an error and is forced to close the connection.

1000 Normal Closure

The 1000 Normal Closure status code indicates that the WebSocket connection was closed normally. This status code is usually sent by the server to the client when the server decides to close the connection.

Handling WebSockets 101 Status Codes

Handling WebSocket 101 status codes is essential when developing WebSocket applications. When a WebSocket connection encounters an error, the application must handle the error in a specific way to ensure that the connection remains stable and that the user experience is not affected.

One of the most common ways to handle WebSocket 101 status codes is to use a WebSocket library that provides error handling and reconnection capabilities. Many WebSocket libraries, such as Socket.IO and SignalR, provide built-in error handling and reconnection mechanisms that make it easy to handle WebSocket errors.

Additionally, when developing WebSocket applications, it is essential to understand the WebSocket 101 status codes and what they signify. This knowledge enables developers to identify and troubleshoot errors quickly, ensuring that the application remains stable and reliable.

FAQs

What are WebSockets?

WebSockets are a technology that allows for real-time communication between a client and a server. Unlike traditional HTTP requests that follow a request-response pattern, WebSockets enable bidirectional communication, meaning that both the client and server can send and receive data at any time.

What are WebSocket 101 status codes?

WebSocket 101 status codes are an essential part of the WebSocket protocol. They indicate the state of the WebSocket connection and provide information on any errors that may occur during the connection.

How do I handle WebSocket 101 status codes?

Handling WebSocket 101 status codes is essential when developing WebSocket applications. One of the most common ways to handle WebSocket 101 status codes is to use a WebSocket library that provides error handling and reconnection capabilities. Additionally, it is essential to understand the WebSocket 101 status codes and what they signify.

What are some common WebSocket 101 status codes?

Some of the most common WebSocket 101 status codes include 101 Switching Protocols, 1006 Abnormal Closure, and 1000 Normal Closure. Each status code has a specific meaning and indicates the state of the WebSocket connection.

Некоторые коды ошибок WebSocket, которые могут возникнуть в процессе работы:

— 1000 — нормальное закрытие соединения
— 1001 — клиент закрыл соединение из-за ошибки на стороне сервера или других причин
— 1002 — сервер закрыл соединение из-за неподдерживаемого типа данных
— 1003 — соединение было закрыто из-за ошибки на стороне клиента
— 1005 — резервированный код, не используется
— 1006 — соединение было закрыто из-за потери соединения или других причин, которые не могут быть определены локально
— 1007 — соединение было закрыто из-за ошибки в данных, которые получил клиент
— 1008 — соединение было закрыто из-за ошибки в данных, которые получил сервер
— 1009 — соединение было закрыто из-за превышения настройки размера сообщения
— 1010 — соединение было закрыто из-за неподдерживаемого типа данных или протокола
— 1011 — соединение было закрыто из-за неизвестной ошибки

Это не полный список кодов, а только некоторые наиболее распространенные.

Browser-side error events are actually related to «close codes» used by the WebSocket protocol, as detailed in section 11.7 to the RFC.

You can find the registered WebSocket closure codes here.

In addition to server-side specified errors, some parsing errors and protocol errors are also emitted by the client (such as UTF-8 requirements)… which are often mapped to a closure code (UTF-8 is mapped to code 1003).

AFAIK, these closure error codes are actually sent to the onclose callback, as part of the close event. (i.e., close_event.code). However, according to MDN when the closure isn’t normal (code 1000), the onerror callback is also called.

Personally I’ve never tested or coded anything with these error-codes, since they are unreliable and optional:

When closing an established connection (e.g., when sending a Close frame, after the opening handshake has completed), an endpoint MAY indicate a reason for closure.

Exposing these «error codes» is optional for a reason. Sending error codes from a server to a client / application could (potentially) expose security vulnerabilities.