También disponible en: English · Português · Français · العربية
Códigos de cierre de WebSocket
La lista completa de IANA, con los códigos que el RFC 6455 prohíbe poner en una trama Close marcados como lo que son, incluido el que probablemente te ha traído aquí.
Qué es un código de cierre de WebSocket
Cuando una conexión WebSocket termina de forma limpia, el lado que la cierra envía una trama Close con un número de cuatro dígitos que explica el motivo. El 1000 significa que la conexión terminó con normalidad, el 1001 que el extremo se va, el 1011 que el servidor se encontró con una condición inesperada. Tu biblioteca cliente te muestra ese número, y suele ser la única pista que tienes sobre lo que ha fallado.
Los números los gestiona IANA en un registro de veinticuatro filas: dieciséis códigos individuales en los 1000, unas pocas asignaciones en los 3000 y varios tramos sin asignar o reservados para que los definas tú. Esta página los lista todos, con buscador, y un número sin fila propia se resuelve al tramo en el que cae.
Además marca algo que el registro no puede marcar. Tres de esos códigos no son mensajes en absoluto, y uno de ellos es casi seguro el motivo por el que estás leyendo esto.
Cómo se usa
- Escribe el número que te ha dado el cliente. La fila correspondiente sale la primera. Si el número no tiene fila propia —cualquiera de los 2000, o uno de uso privado en los 4000— obtienes el rango que lo cubre en vez de nada.
- Lee el estado, no solo el significado. Cada fila dice si el código puede enviarse de verdad. Esa es la columna que te dice si lo eligió el otro lado o se lo inventó tu propia biblioteca.
- Busca también por palabras. Escribir parte de un significado funciona —abnormal, policy, restart—, que es más rápido cuando recuerdas a medias la frase pero no el número.
El 1006 no es un mensaje del servidor
Esta es la parte que merece la pena llevarse. Tres códigos —1005, 1006 y 1015— llevan cada uno en el RFC 6455 una frase que dice que son valores reservados que no deben ponerse como código de estado en una trama de control Close. No son cosas que un extremo pueda enviar. Existen para que una biblioteca tenga algo que informar cuando no hay nada que informar.
El 1006 significa que tu cliente nunca recibió ninguna trama Close. Nadie lo eligió y nadie lo envió; la biblioteca lo rellenó para describir una conexión que sencillamente se paró. Así que la causa está por debajo del protocolo: una conexión TCP caída, un proxy o un balanceador que agotó el tiempo del socket, una red que se fue, o un handshake que nunca se completó. Rebuscar en los registros del servidor quién envió el 1006 es buscar a alguien que no existe.
El 1005 es la misma idea un paso más allá: sí llegó una trama Close, pero no traía ningún código de estado, lo cual es legal. Y el 1015 informa de que TLS falló antes de que hubiera WebSocket del que hablar. Los tres son tu propio lado describiendo su situación, con el vocabulario que la especificación apartó justo para eso.
Hay un cuarto estado que es fácil meter en el mismo saco y no debería. El 1004 está reservado con su significado sin definir, y no lleva ninguna cláusula que prohíba enviarlo: es simplemente un número al que nadie ha dado un trabajo. Cuatro estados, pues, donde una tabla copiada del registro muestra dos.
Lo que el registro dice y lo que no
IANA publica cinco columnas por fila: el código de estado, su significado, un contacto, una referencia y un responsable de cambios. No hay ninguna columna sobre si un código puede enviarse, y no hay forma de añadirla sin cambiar el esquema del registro. La distinción vive solo en la prosa de la sección 7.4.1 del RFC 6455.
Por eso tantas tablas publicadas la pierden. El 1000 y el 1006 son filas de la misma forma, con el mismo tipo de significado y la misma referencia al mismo RFC, así que una tabla generada desde el registro las dibuja idénticas. Nada en los datos dice que uno es un mensaje y el otro una ficción local.
Tres códigos tienen una procedencia que vale la pena mostrar en vez de disimular. El 1012, el 1013 y el 1014 —reinicio del servicio, inténtalo más tarde y un error de pasarela que imita deliberadamente el 502 de HTTP— no los definió ningún documento normativo. Se registraron con un mensaje a una lista de correo, y la columna de referencia del registro enlaza a ese mensaje en vez de a un RFC. Funcionan, están ampliamente implementados, y llegaron ahí por un camino distinto al de todo lo que los rodea.
La limitación honesta de una página así es que es una instantánea de un registro que puede ganar filas. Lo que evita que envejezca en silencio es que el generador se niega a construir si el RFC 6455 ya no contiene la frase exacta que atribuye a cada uno de los tres códigos que nunca se envían, así que la clasificación no puede alejarse de su fuente sin que falle la compilación.
¿Por qué es gratis?
La lista entera está en la página, y buscar en ella ocurre en tu navegador. No hay nada que ejecutar en un servidor ni motivo para pedirte una cuenta.
Nada de lo que escribes se sube, se guarda ni se registra. Sueles llegar aquí con un código sacado de un log de producción, y la forma fiable de mantener eso en privado es no recibirlo nunca.