Lista de códigos de estado HTTP

El código de estado HTTP es parte de la primera línea de la respuesta del servidor para solicitudes HTTP .  Es un número decimal de tres dígitos. El primer dígito indica la clase de estado . El código de respuesta suele ir seguido de una frase explicativa separada por espacios en inglés, que explica a la persona el motivo de tal respuesta. Ejemplos:

• 201 Creado .
• 401 No autorizado .
• 507 Almacenamiento insuficiente .

El cliente aprende del código de respuesta sobre los resultados de su solicitud y determina qué acciones tomar a continuación. El conjunto de códigos de estado es un estándar y se describen en los documentos RFC pertinentes . La introducción de nuevos códigos solo debe realizarse después de consultar con el IETF . Sin embargo, hay dos códigos conocidos en uso que no se mencionan en el RFC: 449 Retry With. También se menciona la frase explicativa "Responder con" [1] en la especificación para WebDAV en Microsoft Developer Network presentada por Microsoft e 509 Bandwidth Limit Exceededintroducida en cPanel .

Es posible que el cliente no conozca todos los códigos de estado, pero debe responder de acuerdo con la clase de código. Actualmente hay cinco clases de códigos de estado.

El servidor web de Internet Information Services en sus archivos de registro, además de los códigos de estado estándar, utiliza subcódigos, escribiéndolos con un punto después del principal. Al mismo tiempo, este subcódigo no se coloca en las respuestas del servidor; el administrador del servidor lo necesita para poder determinar con mayor precisión las fuentes de los problemas.

Lista de revisión

La siguiente es una lista general de todos los códigos de respuesta descritos en este artículo:

• 1xx: informativo
  • 100 Continuar [ 2] [3] ;
  • 101 Protocolos de conmutación [ 2] [3] ;
  • 102 Procesamiento ("procesamiento");
  • 103 Early Hints ("meta-información temprana");
• 2xx: Éxito
  • 200 OK ("bien") [2] [3] ;
  • 201 Creado [ 2] [3] [4] ;
  • 202 Aceptado [ 2] [3] ;
  • 203 Información no autorizada [ 2] [3] ;
  • 204 Sin contenido [ 2] [3] ;
  • 205 Restablecer contenido [ 2] [3] ;
  • 206 Contenido parcial [ 2] [3] ;
  • 207 Multiestado ("multiestado") [5] ;
  • 208 Ya Reportado [ 6] ;
  • 226 MI usado .
• 3xx: Redirección :
  • 300 opciones múltiples [ 2] [7] ;
  • 301 Movido permanentemente [2] [7] ;
  • 302 Movido temporalmente [ 2] [7] , 302 Encontrado [ 7] ;;
  • 303 Ver Otro (“ver otro”) [2] [7] ;
  • 304 No modificado [ 2] [7] ;
  • 305 Usar proxy [ 2] [7] ;
  • 306  - reservado (el código se usó solo en las primeras especificaciones) [7] ;
  • 307 Redirección temporal ("redirección temporal") [7] ;
  • Redirección permanente 308 [ 8] .
• 4xx: error del cliente :
  • 400 Bad Request ("solicitud incorrecta, incorrecta") [2] [3] [4] ;
  • 401 No autorizado ("no autorizado (no se presentó)") [2] [3] ;
  • 402 Pago requerido [ 2] [3] ;
  • 403 Prohibido ("prohibido (no autorizado)") [2] [3] ;
  • 404 No encontrado [ 2] [3] ;
  • 405 Método no permitido [2] [3] ;
  • 406 No aceptable [ 2] [3] ;
  • 407 Se requiere autenticación de proxy [ 2] [3] ;
  • 408 Tiempo de espera de solicitud [ 2] [3] ;
  • 409 Conflicto ("conflicto") [2] [3] [4] ;
  • 410 Ido [ 2] [3] ;
  • 411 Longitud requerida [ 2] [3] ;
  • 412 Precondición fallida [ 2] [3] [9] ;
  • 413 Carga útil demasiado grande [2] [3] ;
  • 414 URI demasiado largo (" URI demasiado largo") [2] [3] ;
  • 415 Tipo de medio no admitido [ 2] [3] ;
  • 416 Rango no satisfactorio [3] ;
  • 417 Expectativa fallida [ 3] ;
  • 418 Soy una tetera ("Soy una tetera");
  • 419 Tiempo de espera de autenticación (no en RFC 2616) ("por lo general, la validación de CSRF falló");
  • 421 Solicitud mal dirigida [10] ;
  • 422 Entidad no procesable
  • 423 Bloqueado ("bloqueado");
  • 424 Dependencia fallida
  • 425 Demasiado temprano ("demasiado temprano");
  • 426 Actualización requerida
  • 428 Precondición requerida [ 11] ;
  • 429 Demasiadas solicitudes [ 11] ;
  • 431 Campos de encabezado de solicitud demasiado grandes [ 11] ;
  • 449 Reintentar con [ 1] ;
  • 451 No disponible por razones legales [ 12] .
  • 499 Solicitud cerrada del cliente (el cliente cerró la conexión);
• 5xx: error del servidor :
  • 500 Error interno del servidor [ 2] [3] ;
  • 501 No implementado [ 2] [3] ;
  • 502 Puerta de enlace incorrecta [ 2] [3] ;
  • 503 Servicio no disponible [ 2] [3] ;
  • 504 Tiempo de espera de puerta de enlace [ 2] [3] ;
  • 505 Versión HTTP no admitida [ 2] [3] ;
  • Variante 506 También Negocia [ 13] ;
  • 507 Almacenamiento insuficiente ("desbordamiento de almacenamiento");
  • 508 Bucle detectado [ 14] ;
  • 509 Límite de ancho de banda excedido ("ancho de banda del canal agotado");
  • 510 No prorrogado ("no prorrogado");
  • 511 Se requiere autenticación de red [ 11] ;
  • 520 Error desconocido ("error desconocido") [15] ;
  • 521 El servidor web está inactivo [15] ;
  • 522 Connection Timed Out ("la conexión no responde") [15] ;
  • 523 El origen es inalcanzable [ 15] ;
  • 524 Ocurrió un tiempo de espera [ 15] ;
  • 525 Protocolo de enlace SSL fallido [ 15] ;
  • 526 Certificado SSL no válido [ 15] .

Descripción de los códigos

Informativo

Esta clase contiene códigos que informan sobre el proceso de transmisión. Al trabajar con la versión 1.0 del protocolo, los mensajes con dichos códigos deben ignorarse. En la versión 1.1, el cliente debe estar preparado para aceptar esta clase de mensaje como una respuesta normal, pero el servidor no necesita enviar nada. Los mensajes del propio servidor contienen solo la línea de inicio de la respuesta y, si es necesario, algunos campos de encabezado específicos de la respuesta. Los servidores proxy deben enviar dichos mensajes más allá del servidor al cliente.

• 100 Continuar: el servidor está satisfecho con la información inicial sobre la solicitud, el cliente puede continuar enviando encabezados. Introducido en HTTP/1.1.
• 101 Protocolos de conmutación: el servidor cumple con la solicitud del cliente y cambia los protocolos de acuerdo con la indicación dada en el campo del encabezado Upgrade. El servidor envía un encabezado de respuesta Upgradeque indica el protocolo al que ha cambiado. Introducido en HTTP/1.1.
• 102 Procesando: la solicitud fue aceptada, pero llevará mucho tiempo procesarla. Utilizado por el servidor para evitar que el cliente finalice la conexión debido a un tiempo de espera. El cliente, al recibir tal respuesta, debe reiniciar el temporizador y esperar el próximo comando en el modo normal. Apareció en WebDAV .
• 103 Early Hints: se utiliza para devolver parte de los encabezados antes de tiempo cuando los encabezados de respuesta completos no se pueden formar rápidamente.

Éxito

Los mensajes de esta clase informan sobre casos de aceptación y procesamiento exitosos de una solicitud de cliente. Según el estado, el servidor también puede enviar encabezados y un cuerpo de mensaje.

• 200 OK - solicitud exitosa. Si algún dato fue solicitado por el cliente, se encuentra en el encabezado y/o cuerpo del mensaje. Introducido en HTTP/1.0.
• 201 Creado: se creó un nuevo recurso como resultado de una solicitud exitosa. El servidor PUEDE especificar las direcciones (puede haber más de una) del recurso creado en el cuerpo de la respuesta, con la dirección preferida indicada en el Location. Se recomienda al servidor indicar en el cuerpo de la respuesta las características del recurso creado y su dirección, el formato del cuerpo de la respuesta lo determina el encabezado Content-Type. Al procesar una solicitud, se debe crear un nuevo recurso antes de enviar la respuesta al cliente, de lo contrario, una respuesta con código 202. Introducido en HTTP/1.0.
• 202 Aceptado: la solicitud se aceptó para su procesamiento, pero no se completó. El cliente no tiene que esperar a la transmisión final del mensaje, ya que se puede iniciar un proceso muy largo. Introducido en HTTP/1.0.
• 203 Información no autorizada: similar a 200, pero en este caso, la información que se transmite no se tomó de la fuente principal (copia de seguridad, otro servidor, etc.) y, por lo tanto, es posible que no esté actualizada. Introducido en HTTP/1.1.
• 204 Sin contenido: el servidor procesó correctamente la solicitud, pero solo se enviaron encabezados en la respuesta sin un cuerpo de mensaje. El cliente no tiene que actualizar el contenido del documento, pero puede aplicarle los metadatos recibidos . Introducido en HTTP/1.0.
• 205 Restablecer Contenido - El servidor obliga al cliente a restablecer los datos ingresados ​​por el usuario. El servidor no transmite el cuerpo del mensaje y no es necesario actualizar el documento. Introducido en HTTP/1.1.
• 206 Contenido parcial: el servidor completó con éxito una solicitud GET parcial y devolvió solo una parte del mensaje. En el encabezado, el Content-Rangeservidor especifica los rangos de bytes del contenido. Al trabajar con este tipo de respuestas, se debe prestar especial atención al almacenamiento en caché. Introducido en HTTP/1.1. ( más… )
• 207 Multi-Status: el servidor transmite los resultados de varias operaciones independientes a la vez. Se colocan en el propio cuerpo del mensaje como un documento XMLmultistatus con extensión . No se recomienda colocar estados de la serie en este objeto debido 1xxa la falta de sentido y la redundancia. Apareció en WebDAV .
• 208 Ya informado: los miembros vinculantes de DAV ya se enumeraron en la parte anterior (multiestado) de la respuesta y no se incluyen nuevamente.
• 226 IM Usado: el encabezado A-IMse recibió con éxito del cliente y el servidor devuelve el contenido, teniendo en cuenta los parámetros especificados. Introducido en RFC 3229 para aumentar el protocolo HTTP con soporte para codificación delta .

Redirección

Los códigos de esta clase le dicen al cliente que se debe realizar otra solicitud para que la operación tenga éxito, generalmente en un URI diferente . De esta clase, cinco códigos 301, 302, y 303se refieren directamente a redireccionamientos. La dirección a la que el cliente debe realizar una solicitud la indica el servidor en el . Esto permite que se utilicen fragmentos en el URI de destino. 305307Location

De acuerdo con los últimos estándares, el cliente solo puede redirigir sin preguntar al usuario si se solicita el segundo recurso utilizando el método GETo HEAD[7] . Las especificaciones anteriores decían que para evitar viajes de ida y vuelta, se debe preguntar al usuario después de la quinta redirección consecutiva [16] . Para todos los redireccionamientos, si el método de solicitud no fue HEAD, se debe incluir un breve mensaje de hipertexto con la dirección de destino en el cuerpo de la respuesta, de modo que, en caso de error, el usuario pueda navegar por sí mismo.

Los desarrolladores de HTTP notan que muchos clientes, al redirigir con códigos 301, 302aplican erróneamente el método GETal segundo recurso, a pesar de que la primera solicitud fue con un método diferente (la mayoría de las veces PUT) [17] . Para evitar malentendidos, se recomienda utilizar los códigos HTTP/1.1 303y y en lugar de . Solo necesita cambiar el método si el servidor respondió . En otros casos, la siguiente solicitud se realiza con el método original. 307302303

El comportamiento de los clientes para varios redireccionamientos se describe en la tabla:

Estado de respuesta	almacenamiento en caché	Si el método no es GET o HEAD
301 Moved Permanently	Puedes como de costumbre.	Pida confirmación al usuario y solicite otro recurso utilizando el método original.
307 Temporary Redirect	Solo es posible si un título Cache-Controlo Expires.
302 Found(HTTP/1.1) 302 Moved Temporarily(HTTP/1.0)
303 See Other	esta prohibido	Ir automáticamente, pero usando el GET.

• 300 Opciones múltiples: en el URI especificado, hay varias opciones para proporcionar un recurso por tipo MIME , por idioma u otras características. El servidor envía una lista de alternativas con el mensaje, permitiendo que la elección sea realizada automáticamente por el cliente o el usuario. Introducido en HTTP/1.0.
• 301 Movido permanentemente  : el documento solicitado se ha movido permanentemente al nuevo URI especificado en el Locationcampo de encabezado. Algunos clientes se comportan incorrectamente al procesar este código. Introducido en HTTP/1.0.
• 302 encontrado, 302 movido temporalmente: el documento solicitado está disponible temporalmente en un URI diferente especificado en el encabezado del archivo Location. Este código se puede utilizar, por ejemplo, en la negociación de contenido impulsada por el servidor . Alguno[ ¿Qué? ] los clientes se comportan incorrectamente al procesar este código. Introducido en HTTP/1.0.
• 303 Ver Otro - El documento en la URI solicitada debe solicitarse en la dirección en el Locationcampo de encabezado usando el método GET, aunque el primero fue solicitado por un método diferente. Este código se introdujo junto con el código 307para evitar la ambigüedad, de modo que el servidor pueda estar seguro de que el siguiente recurso será solicitado por GET. Por ejemplo, una página web tiene un campo de entrada de texto para una navegación y búsqueda rápidas. Después de ingresar los datos, el navegador realiza una solicitud utilizando el método POST, incluyendo el texto ingresado en el cuerpo del mensaje. Si se encuentra un documento con el nombre ingresado, el servidor responde con el código 303, indicando Locationsu dirección permanente en el encabezado. Luego, se garantiza que el navegador lo solicitará con un método GETpara obtener el contenido. De lo contrario, el servidor simplemente devolverá la página de resultados de búsqueda al cliente. Introducido en HTTP/1.1.
• 304 No modificado: el servidor devuelve este código si el cliente solicitó el documento mediante el GETencabezado If-Modified-Sinceo If-None-Matchy el documento no ha cambiado desde el momento especificado. En este caso, el mensaje del servidor no debe contener cuerpo. Introducido en HTTP/1.0.
• 305 Use Proxy: la solicitud del recurso solicitado debe realizarse a través de un servidor proxy cuya URI se especifica en el Locationcampo de encabezado. Este código de respuesta solo lo pueden usar los servidores HTTP de origen (no los servidores proxy). Introducido en HTTP/1.1.
• 306 (Reservado): utilizado en versiones anteriores de la especificación, el código de respuesta está actualmente reservado. Mencionado en RFC 2616 (actualización HTTP/1.1). Según los primeros borradores, el código significaba Switch Proxy, diciéndole al cliente que cambiara el proxy en uso por el especificado por el servidor en el encabezado de respuesta [18] .
• Redirección temporal 307: el recurso solicitado está disponible brevemente en un URI diferente especificado en el Locationcampo de encabezado. No se permite cambiar el método de solicitud (GET/POST). Por ejemplo, una solicitud POST debe enviarse a un nuevo URI usando el mismo método POST. Este código se introdujo junto con 303 en lugar de 302 para evitar ambigüedades. Introducido en RFC 2616 (actualización HTTP/1.1).
• Redirección permanente 308: el recurso solicitado se ha reubicado de forma permanente en el nuevo URI especificado en el Locationcampo de encabezado. No se permite cambiar el método de solicitud (GET/POST). Por ejemplo, una solicitud POST debe enviarse a un nuevo URI usando el mismo método POST. Este código se introdujo en lugar del 301 para evitar ambigüedades. Introducido en RFC 7238 ( RFC 7538 ).

Error del cliente

La clase de códigos 4xxestá destinada a indicar errores en el lado del cliente. Cuando se utilizan todos los métodos excepto HEAD, el servidor debe devolver una explicación de hipertexto para el usuario en el cuerpo del mensaje.

• 400 Solicitud incorrecta: el servidor encontró un error de sintaxis en la solicitud del cliente. Introducido en HTTP/1.0.
• 401 No autorizado: se requiere autenticación para acceder al recurso solicitado . El encabezado de respuesta debe contener un campo WWW-Authenticatecon una lista de condiciones de autenticación. Es decir, para acceder al recurso solicitado, el cliente debe presentarse enviando una solicitud, incluyendo Authorizationen la cabecera del mensaje un campo con los datos necesarios para la autenticación. Si la solicitud ya incluye datos de autorización, una respuesta 401 significa que se deniega la autorización.
• 402 Pago requerido: destinado a ser utilizado en el futuro[ ¿cuándo? ] . Actualmente[ ¿cuándo? ] no se utiliza. Este código es para servicios de usuario de pago, no para empresas de hosting . Significa que este error no será emitido por el proveedor de alojamiento en caso de pago atrasado de sus servicios. Reservado desde HTTP/1.1.

• 403 Prohibido [19]  - El servidor entendió la solicitud, pero se niega a cumplirla debido a restricciones en el acceso del cliente al recurso especificado. En otras palabras, el cliente no está autorizado para realizar operaciones en el recurso solicitado. Si el acceso a un recurso requiere autenticación HTTP, el servidor devolverá una respuesta 401, o 407cuando utilice un proxy. De lo contrario, los límites los ha establecido el administrador del servidor o el desarrollador de la aplicación web y pueden variar según las capacidades del software que se utilice . En todo caso, el servidor DEBE ser informado de los motivos por los que se niega a tramitar la solicitud. Los motivos más probables de la restricción pueden ser un intento de acceder a los recursos del sistema del servidor web (por ejemplo, archivos .htaccesso .htpasswd) o archivos a los que se denegó el acceso mediante archivos de configuración, el requisito de autenticación distinta de HTTP, por ejemplo, para accede al gestor de contenidos oa la sección para usuarios registrados, o el servidor no está satisfecho con la dirección IP del cliente , por ejemplo, cuando está bloqueado. Introducido en HTTP/1.0.
• 404 Not Found [20]  es el error más común al utilizar Internet, el principal motivo es un error al escribir la dirección de una página Web. El servidor entendió la solicitud, pero no encontró un recurso coincidente en la URL especificada. Si el servidor sabe que había un documento en esta dirección, entonces es deseable usar el código 410 . La respuesta 404se puede usar en lugar 403de si desea ocultar cuidadosamente ciertos recursos de miradas indiscretas. Introducido en HTTP/1.0.
• 405 Método no permitido: el método especificado por el cliente no se puede aplicar al recurso actual. En la respuesta, el servidor debe indicar los métodos disponibles en el encabezado Allow, separados por una coma. El servidor debe devolver este error si conoce el método, pero no es aplicable específicamente al recurso especificado en la solicitud, pero si el método especificado no es aplicable en todo el servidor, entonces el cliente debe devolver el código 501( No se ha implementado). Introducido en HTTP/1.1.
• 406 No aceptable: el URI solicitado no puede satisfacer las características pasadas en el encabezado. Si el método no era HEAD, el servidor debería devolver una lista de características válidas para el recurso dado. Introducido en HTTP/1.1.
• 407 Se requiere autenticación de proxy: la respuesta es similar al código 401, excepto que la autenticación se realiza para un servidor proxy. El mecanismo es similar a la autenticación en el servidor de origen. Introducido en HTTP/1.1.
• 408 Tiempo de espera de solicitud: el servidor superó el tiempo de espera de una transferencia del cliente. El cliente puede repetir la solicitud similar a la anterior en cualquier momento. Por ejemplo, tal situación puede ocurrir al cargar un archivo grande en el servidor usando POSTo PUT. En algún momento de la transferencia, la fuente de datos dejó de responder, por ejemplo, debido a un CD dañado oa una pérdida de comunicación con otra computadora en la red local. Mientras el cliente no transmita nada, esperando una respuesta del mismo, se mantiene la conexión con el servidor. Después de un tiempo, el servidor puede cerrar la conexión de su lado para permitir que otros clientes realicen una solicitud. Esta respuesta no se devuelve cuando el cliente detuvo la transferencia a la fuerza por orden del usuario o la conexión se interrumpió por algún otro motivo, ya que la respuesta ya no se puede enviar. Introducido en HTTP/1.1.
• 409 Conflicto: la solicitud no se pudo completar debido a un conflicto de recursos. Esto puede suceder, por ejemplo, cuando dos clientes intentan modificar un recurso utilizando el PUT. Introducido en HTTP/1.1.
• 410 Gone: el servidor envía dicha respuesta si el recurso solía estar en la URL especificada, pero se eliminó y ahora no está disponible. En este caso, el servidor tampoco conoce la ubicación del documento alternativo (por ejemplo, una copia). Introducido en HTTP/1.1.
• 411 Longitud requerida: para el recurso especificado, el cliente debe especificarlo Content-Lengthen el encabezado de la solicitud. Sin especificar este campo, no debe volver a intentar la solicitud al servidor para este URI. Tal respuesta es natural para consultas como POSTy PUT. Por ejemplo, si los archivos se descargan en el URI especificado y hay un límite en su volumen en el servidor. Entonces sería más inteligente comprobar el encabezado desde el principio Content-Lengthy rechazar inmediatamente la descarga, que provocar una carga sin sentido interrumpiendo la conexión cuando el cliente realmente envía un mensaje que es demasiado grande. Introducido en HTTP/1.1.
• 412 Precondición fallida: se devuelve si ninguno de los campos de encabezado condicionales (If-Match, etc., consulte RFC 7232 ) de la solicitud se ha completado. Introducido en HTTP/1.1.
• 413 Carga útil demasiado grande: se devuelve si el servidor se niega a procesar la solicitud porque el cuerpo de la solicitud es demasiado grande. El servidor PUEDE cerrar la conexión para detener la transmisión de la solicitud. Si el problema es temporal, se recomienda incluir un encabezado en la respuesta del servidor que Retry-Afterindique el tiempo después del cual se puede repetir una solicitud similar. Introducido en HTTP/1.1. Anteriormente llamado "Entidad de solicitud demasiado grande".
• 414 URI demasiado largo: el servidor no puede procesar la solicitud porque el URI especificado es demasiado largo. Tal error puede ser provocado, por ejemplo, cuando el cliente intenta pasar parámetros largos a través del método GETen lugar de POST. Introducido en HTTP/1.1. Anteriormente llamado "URI de solicitud demasiado largo".
• 415 Tipo de medio no admitido: por alguna razón, el servidor se niega a trabajar con el tipo de datos especificado con este método. Introducido en HTTP/1.1.
• 416 Rango no satisfactorio: Rangese especificó un rango fuera del recurso en el campo del encabezado de la solicitud y falta el campo If-Range. Si el cliente envió un rango de bytes, entonces el servidor PUEDE devolver el tamaño real en el Content-Rangecampo de encabezado. Esta respuesta no debe usarse al pasar el tipomultipart/byteranges . Introducido en RFC 2616 (actualización HTTP/1.1). Anteriormente llamado "Rango solicitado no satisfactorio".
• 417 Expectativa fallida: por alguna razón, el servidor no puede satisfacer el valor del Expectcampo del encabezado de la solicitud. Introducido en RFC 2616 (actualización HTTP/1.1).
• 418 Soy una tetera: este código se introdujo en 1998 como una de las bromas tradicionales de IETF April Fools en RFC 2324 , Hyper Text Coffee Pot Control Protocol . No se espera que este código sea compatible con servidores reales [21] .
• Tiempo de espera de autenticación 419 (no en RFC 2616 ): este código no está en RFC 2616 , se usa como una alternativa a los códigos 401 que se autentican pero se les niega el acceso a ciertos recursos del servidor. Por lo general, el código se proporciona si el token CSRF está desactualizado o resultó ser incorrecto.
• 421 Solicitud mal dirigida: la solicitud se redirigió a un servidor que no pudo responder.
• 422 Entidad no procesable: el servidor aceptó correctamente la solicitud, puede trabajar con el tipo de datos especificado (por ejemplo, el cuerpo de la solicitud contiene un documento XML que tiene la sintaxis correcta), pero hay algún tipo de error lógico por el cual es imposible realizar una operación en el recurso. Introducido en WebDAV .
• 423 Bloqueado: el recurso de destino de la solicitud no puede aplicarle el método especificado. Introducido en WebDAV .
• 424 Dependencia fallida: la implementación de la solicitud actual puede depender del éxito de otra operación. Si no se ejecuta y debido a esto es imposible ejecutar la solicitud actual, entonces el servidor devolverá este código. Introducido en WebDAV .
• 425 Demasiado temprano: el servidor no está listo para aceptar los riesgos de procesar "información temprana". Introducido en RFC 8470 para proteger contra ataques de reproducción cuando se usa 0-RTT en TLS 1.3.
• 426 Actualización requerida: el servidor le indica al cliente que actualice el protocolo. El encabezado de la respuesta debe contener campos bien formados Upgradey Connection. Introducido en RFC 2817 para permitir la transición a TLS sobre HTTP.
• 428 Precondición requerida: el servidor le dice al cliente que use encabezados de condición como If-Match. Introducido en el borrador RFC 6585 .
• 429 Demasiadas solicitudes: el cliente intentó enviar demasiadas solicitudes en poco tiempo, lo que puede indicar, por ejemplo, un intento de ataque DDoS. Puede ir acompañado de un encabezado Reintentar después que indica durante cuánto tiempo se puede volver a intentar la solicitud. Introducido en el borrador RFC 6585 .
• 431 Solicitar campos de encabezado demasiado grandes: se ha excedido la longitud permitida de los encabezados. No se requiere que el servidor responda con este código, sino que simplemente puede restablecer la conexión. Introducido en el borrador RFC 6585 .
• 434 Host solicitado no disponible: la dirección solicitada no está disponible .
• 449 Reintentar con: lo devuelve el servidor si no se recibió suficiente información del cliente para procesar la solicitud. En este caso, el campo se coloca en el encabezado de respuesta Ms-Echo-Request. Introducido por Microsoft para WebDAV . Actualmente[ ¿cuándo? ] es utilizado por al menos Microsoft Money .
• 451 No disponible por razones legales  : el acceso al recurso está cerrado por razones legales, por ejemplo, a pedido de las autoridades públicas o a pedido del titular de los derechos de autor en caso de infracción de derechos de autor. Introducido en un borrador de IETF por Google [12] , con el código de error siendo una referencia a la novela Fahrenheit 451 de Ray Bradbury . Se añadió a la norma el 21 de diciembre de 2015 [22] .
• 499 Client Closed Request es un código no estándar propuesto y utilizado por nginx para casos en los que el cliente cerró la conexión mientras nginx procesaba la solicitud.

Error del servidor

Los códigos 5xxestán dedicados a casos de excepciones no controladas al realizar operaciones en el lado del servidor. Para todas las situaciones que no sean el uso del método HEAD, el servidor DEBE incluir una explicación en el cuerpo del mensaje que el cliente mostrará al usuario.

• 500 Error interno del servidor [23]  Cualquier error interno del servidor que no esté cubierto por el resto de errores de clase. Introducido en HTTP/1.0.
• 501 No implementado: el servidor no admite las capacidades necesarias para procesar la solicitud. Una respuesta típica para casos en los que el servidor no comprende el método especificado en la solicitud. Si el servidor conoce el método, pero no es aplicable a este recurso, entonces debe devolver la respuesta 405. Introducido en HTTP/1.0.
• 502 Puerta de enlace incorrecta: el servidor, que actúa como puerta de enlace o servidor proxy, recibió un mensaje de respuesta no válido de un servidor ascendente. Introducido en HTTP/1.0.
• 503 Servicio no disponible: el servidor no puede procesar temporalmente las solicitudes por razones técnicas (mantenimiento, sobrecarga, etc.). En el Retry-Aftercampo de encabezado, el servidor puede especificar el tiempo después del cual se recomienda que el cliente repita la solicitud. Aunque parece obvio terminar inmediatamente la conexión durante la congestión, puede ser más eficiente configurar el campo en un valor grande Retry-Afterpara reducir la frecuencia de las solicitudes redundantes. Introducido en HTTP/1.0.
• 504 Tiempo de espera de puerta de enlace: el servidor que actúa como puerta de enlace o proxy no esperó una respuesta del servidor ascendente para completar la solicitud actual. Introducido en HTTP/1.1.
• 505 Versión HTTP no admitida: el servidor no admite o se niega a admitir la versión del protocolo HTTP especificado en la solicitud. Introducido en HTTP/1.1.
• 506 La variante también negocia: como resultado de una configuración errónea, la variante seleccionada se apunta a sí misma, por lo que se interrumpe el proceso de vinculación. Experimental. Introducido en RFC 2295 para aumentar el protocolo HTTP con tecnología de negociación de contenido transparente .
• 507 Almacenamiento insuficiente: no hay suficiente espacio para completar la solicitud actual. El problema puede ser temporal. Introducido en WebDAV .
• 508 Loop Detected - Operación cancelada porque el servidor encontró un bucle infinito mientras procesaba una solicitud sin límite de profundidad. Introducido en WebDAV .
  • 508 Resource Limit Reached es una variante del error 508 en CloudLinux que ocurre cuando se alcanzan los límites de alojamiento [24] .
• 509 Límite de ancho de banda excedido: se utiliza cuando el sitio web supera el límite de consumo de tráfico que se le ha asignado. En este caso, el propietario del sitio debe ponerse en contacto con su proveedor de alojamiento. Actualmente, este código no se describe en ningún RFC y solo lo usa el módulo "bw/limited" incluido en el panel de control del alojamiento cPanel , donde se introdujo.
• 510 No extendido: el servidor no tiene una extensión que el cliente quiera usar. El servidor puede opcionalmente enviar información sobre las extensiones disponibles para él. Introducido en RFC 2774 para aumentar el protocolo HTTP con soporte para extensiones.
• 511 Se requiere autenticación de red: esta respuesta no la envía el servidor al que estaba destinada la solicitud, sino un servidor intermediario, por ejemplo, el servidor del proveedor, si el cliente primero debe iniciar sesión en la red, por ejemplo, ingrese una contraseña para un punto de acceso a Internet de pago. Se supone que el cuerpo de la respuesta devolverá un formulario de autorización web o una redirección al mismo. Introducido en el borrador RFC 6585 .
• 520 Error desconocido, ocurre cuando el servidor CDN no pudo procesar el error del servidor web; código CloudFlare personalizado .
• 521 El servidor web está inactivo, ocurre cuando el servidor web rechaza las conexiones CDN ; código CloudFlare personalizado .
• 522 Se agotó el tiempo de espera de la conexión, ocurre cuando la CDN no pudo conectarse al servidor web; código CloudFlare personalizado .
• 523 Origin Is Unreachable, ocurre cuando el servidor web es inalcanzable; código CloudFlare personalizado .
• 524 Se agotó el tiempo de espera, se produce cuando se agota el tiempo de conexión entre el servidor CDN y el servidor web. código CloudFlare personalizado .
• 525 SSL Handshake Failed, ocurre cuando falla el protocolo de enlace SSL entre el servidor CDN y el servidor web; código CloudFlare personalizado .
• 526 Certificado SSL no válido, ocurre cuando el certificado de cifrado del servidor web no se puede validar; código CloudFlare personalizado .

Véase también

• Lista de encabezados HTTP
• Código de respuesta

Notas

1. ↑ 1 2 2.2.6 449 "Reintentar con código de estado" // Protocolo de creación y control de versiones distribuido web (WebDAV): Extensiones de cliente. Archivado el 5 de octubre de 2009 en Wayback Machine en MSDN .
2. ↑ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 " 6.1.1 Código de estado y frase de motivo Archivado desde junio 7, 2018 en Wayback Machine » en RFC 2068
3. ↑ 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 RFC 2616 . Fecha de acceso: 29 de julio de 2009. Archivado desde el original el 7 de marzo de 2011. (indefinido)
4. ↑ 1 2 3 IETF Draft WebDAV Advanced Collections Protocol  - S.4.2.5 . Fecha de acceso: 18 de mayo de 2012. Archivado desde el original el 9 de julio de 2012. (indefinido)
5. ↑ IETF Draft WebDAV Advanced Collections Protocol  - S.10 . Fecha de acceso: 18 de mayo de 2012. Archivado desde el original el 9 de julio de 2012. (indefinido)
6. ↑ rfc5842 . Consultado el 12 de septiembre de 2017. Archivado desde el original el 10 de octubre de 2017. (indefinido)
7. ↑ 1 2 3 4 5 6 7 8 9 10 RFC 2616 "10.3 Redirección 3xx" (pág. 61) . Fecha de acceso: 29 de julio de 2009. Archivado desde el original el 7 de marzo de 2011. (indefinido)
8. ↑ rfc7538 . Consultado el 12 de septiembre de 2017. Archivado desde el original el 16 de abril de 2015. (indefinido)
9. ↑ IETF Draft WebDAV Advanced Collections Protocol  - S.4.3.1.1 . Fecha de acceso: 18 de mayo de 2012. Archivado desde el original el 9 de julio de 2012. (indefinido)
10. ↑ rfc7540 . Consultado el 12 de septiembre de 2017. Archivado desde el original el 23 de junio de 2015. (indefinido)
11. ↑ 1 2 3 4 RFC 6585
12. ↑ 1 2 Borrador de IETF Un nuevo código de estado HTTP para informar obstáculos legales . Consultado el 6 de marzo de 2013. Archivado desde el original el 22 de mayo de 2013. (indefinido)
13. ↑ RFC 2295 Negociación de contenido transparente en HTTP  -S.8.1 . Fecha de acceso: 18 de mayo de 2012. Archivado desde el original el 8 de junio de 2012. (indefinido)
14. ↑ IETF Draft WebDAV Advanced Collections Protocol  - S.7.1 . Fecha de acceso: 18 de mayo de 2012. Archivado desde el original el 9 de julio de 2012. (indefinido)
15. ↑ 1 2 3 4 5 6 7 Páginas de error - Soporte de CloudFlare . Consultado el 18 de abril de 2016. Archivado desde el original el 4 de marzo de 2016. (indefinido)
16. ↑ RFC 2068 "10.3 Redirección 3xx" (p. 56) Archivado el 7 de junio de 2018 en Wayback Machine .
17. ↑ RFC 2616 , sección "10.3.3 302 Found", página 63 Archivado el 7 de marzo de 2011 en Wayback Machine .
18. ↑ Josh Cohen HTTP/1.1 Códigos de respuesta 305 y 306 Archivado el 8 de septiembre de 2014 en Wayback Machine  // Netscape Communications Corp., 25 de diciembre de 1996
19. ↑ ¿Qué significa 403 Prohibido? Archivado el 21 de febrero de 2014 en Wayback Machine .
20. ↑ Causas de un error 404 no encontrado Archivado el 21 de febrero de 2014 en Wayback Machine .
21. ↑ RFC 2324 - Protocolo de control de cafetera de hipertexto (HTCPCP/1.0) .
22. ↑ draft-ietf-httpbis-legally-restricted-status-04 . datatracker.ietf.org. Consultado el 22 de diciembre de 2015. Archivado desde el original el 23 de diciembre de 2015. (indefinido)
23. ↑ Descripción del error interno del servidor 500 Archivado el 21 de febrero de 2014 en Wayback Machine .
24. ↑ Límite de recursos alcanzado . www.cloudlinux.com_ _ Consultado el 21 de junio de 2022. Archivado desde el original el 15 de mayo de 2021. (indefinido)

Enlaces

Documentos principales de HTTP (descendentes por fecha de publicación)

•  Registro de código de estado del Protocolo de transferencia de hipertexto (HTTP) . IANA (17 de octubre de 2007). - Registro de código de estado HTTP. Fecha de acceso: 30 de julio de 2009. Archivado desde el original el 17 de febrero de 2012.
• RFC 2616 Borrador estándar " Protocolo de transferencia de  hipertexto  - HTTP/1.1 "  ( inglés ) IETF , junio de 1999; Fielding Roy ( Universidad de California en Irvine )), Gettys Jim ( Compaq / W3C ), Mogul J. ( Compaq ), Frystyk Henrik( MIT / W3C ), Masinter L. ( Xerox ), Leach P. ( Microsoft ), Berners-Lee Tim ( W3C / MIT )  - actualización del protocolo HTTP versión 1.1.
• RFC 2068 Estándar propuesto " Protocolo de transferencia de hipertexto - HTTP/1.1 "  (inglés) (del  inglés  -  "Protocolo de transferencia de hipertexto - HTTP/1.1"); IETF , enero de 1997; Fielding Roy ( Universidad de California en Irvine )), Gettys Jim ( DEC ), Mogul J. ( DEC ), Frystyk Henrik( MIT /LCS), Berners-Lee Tim ( MIT /LCS)  es una de las primeras especificaciones para HTTP versión 1.1.
• RFC 1945 Informativo " Protocolo de transferencia de  hipertexto - HTTP  /  1.0 " IETF , mayo de 1996; Berners-Lee Tim ( MIT /LCS), Fielding Roy ( UC Irvine), Frystyk Henrik( MIT /LCS)  es la primera especificación del protocolo HTTP. También incluye una descripción de HTTP/0.9.

Documentos sobre extensiones y actualizaciones del protocolo HTTP (descendente por fecha de publicación)

• RFC 4918 Propuesta de norma " Extensiones  HTTP para creación y control de  versiones distribuidas en la Web (  WebDAV ) " IETF , junio de 2007; Ed. Dusseault. L. ( ComercioNet)  es una especificación tardía para el protocolo WebDAV, que reemplaza a RFC 2518 .
• RFC 3229 Estándar propuesto " Codificación Delta en HTTP "  (inglés) (del  inglés  -  "Codificación Delta en HTTP"); IETF , enero de 2002; Mogul J. ( Compaq WRL ), Krishnamurthy B. ( AT&T ), Douglis F. ( AT&T ), Feldmann A. ( Universidad de Saarbrücken), Goland Y. (Marimba), van Hoff A. (Marimba), Hellerstein D. (ERS/USDA) .
• Estándar propuesto RFC 2817 " Actualización  a TLS  dentro de HTTP  / 1.1 " IETF , mayo de 2000; Khare Rohit(Asociados 4K/ UC Irvine), Lawrence S. (Agranat Systems, Inc.)  - actualización a RFC 2616 para describir cómo funcionan HTTP y TLS .
• RFC 2774 Experimental " An HTTP Extension Framework "  (inglés) (del  inglés  -  "HTTP Extension Framework"); IETF , febrero de 2000; Nielsen H. ( Microsoft ), Leach P. ( Microsoft ), Lawrence S. (Agranat Systems) .
• Borrador de Internet " Protocolo de colecciones avanzadas de WebDAV " (del  inglés  - "Protocolo de colecciones avanzadas de WebDAV  "); IETF , 18 de junio de 1999; Slein J. ( Xerox ), Whitehead Jr. EJ ( Universidad de California en Irvine )), Davis J. (CourseNet), Clemm G. ( Rational ), Fay C. ( FileNet), Crawford J. ( IBM ), Chihaya T. (DataChannel)  - gestión de colecciones en WebDAV; expiró el 18 de diciembre de 1999.
• RFC 2518 Propuesta de norma "  Extensiones HTTP para  creación distribuida -  WEBDAV " IETF , febrero de 1999; Goland Y. ( Microsoft ), Whitehead E. ( UC Irvine), Faizi A. ( Netscape ), Carter S. ( Novell ), Jensen D. ( Novell )  - la primera especificación para el protocolo WebDAV (reemplazada por RFC 4918 ).
•  RFC 2295  Negociación experimental  de contenido transparente en HTTP IETF , marzo de 1998; Holtman K. (MAR), Mutz A. ( Hewlett-Packard ) .

Materiales adicionales

•  Protocolo Web Distributed Authoring and Versioning (WebDAV) : Extensiones de cliente . Microsoft (14 de marzo de 2007). — Descripción del soporte de extensión de cliente en el protocolo WebDAV. Fecha de acceso: 30 de julio de 2009. Archivado desde el original el 17 de febrero de 2012.
• RFC 2324 Informativo " Protocolo de control de cafetera de hipertexto (  HTCPCP  /  1.0 ) " IETF , 1 de abril de 1998; Maestro L. .
• KB 318380 Códigos de estado de IIS . Microsoft (4 de diciembre de 2007). — lista de códigos de estado ampliados para los protocolos HTTP y FTP. Fecha de acceso: 16 de enero de 2010. Archivado desde el original el 17 de febrero de 2012. (Ruso)
• Manual de códigos de estado HTTP . Yandex . — procesamiento de códigos de estado HTTP por robots Yandex . Recuperado: 2 Mayo 2018. (indefinido)

Web y sitios web
globalmente	La red mundial Internet 1.0 web 2.0 Internet 3.0 web semántica Neuronet
En la zona	Sitio web Portal Página Servicio Anillo
Tipos de sitios y servicios	atlas virtuales red de banners Biblioteca Blog ( plataforma ) Alojamiento de videos wiki sitio de tarjeta de visita Pregunta respuesta Marcadores servicios de citas juego de navegador Directorio de recursos Tienda en línea microblog sitio de noticias Sistema de búsqueda sitio porno correo web Red social Tumblelog Rastreador de BitTorrent Alojamiento de archivos Foro Servicio Tablero de imagen Alojamiento de fotos Charlar
Creación y mantenimiento	Maestro Desarrollo Diseño Diseño Programación usabilidad Experiencia de interacción promoción del sitio web Optimización de motores de búsqueda (SEO) Alojamiento Administrador de sistema Moderador Cuenta Autorización
Tipos de diseños, páginas, sitios.	Estático Dinámica Fijado Goma dinámicamente elástico Adaptado
Técnico	Servidor web Navegador DNS CMF CMS HTTP ( respuestas encabezados ) SPDY RÁPIDO CGI HTML XHTML CSS PHP JavaScript DHTML Galleta DOM XML AJAX JSON Destello RSS átomo informador microformato favicon.ico_ _ robots.txt Mapas del sitio mapa del sitio .htaccess
Marketing	Mercadeo por Internet publicidad en Internet Bandera publicidad contextual Rompecabezas ciberocupación
sociedad y Cultura	Blogosfera Comunidad de Internet ( distrito ) Literatura de red

HTTP
Conceptos generales	Conexión permanente Canalización HTTP Compresión HTTPS HTTP/2 HTTP/3
Métodos	OPCIONES OBTENER CABEZA CORREO PONER ELIMINAR RASTRO CONECTAR PARCHE
Títulos	Galleta ETag referente ubicación HTTP rastrear X-Reenviado-
Códigos de estado	1xx: informativo 2xx: Éxito 3xx: Redirección 301 Movido Permanentemente 4xx: error del cliente 403: Prohibido 404 No encontrado 451: No disponible por razones legales 5xx: error del servidor