Lista de códigos de estado HTTP

Esta es una lista de códigos de estado de respuesta del Protocolo de transferencia de hipertexto (HTTP). Los códigos de estado son emitidos por un servidor en respuesta a la solicitud de un cliente realizada al servidor. Incluye códigos de las Solicitudes de comentarios (RFC) de IETF, otras especificaciones y algunos códigos adicionales utilizados en algunas aplicaciones comunes del HTTP. El primer dígito del código de estado especifica una de las cinco clases estándar de respuestas. Las frases de mensaje opcionales que se muestran son típicas, pero se puede proporcionar cualquier alternativa legible para humanos o ninguna.

A menos que se indique lo contrario, el código de estado es parte del estándar HTTP. ^[1]

La Autoridad de Números Asignados de Internet (IANA) mantiene el registro oficial de los códigos de estado HTTP. ^[2]

Todos los códigos de estado de respuesta HTTP se dividen en cinco clases o categorías. El primer dígito del código de estado define la clase de respuesta, mientras que los dos últimos dígitos no tienen ninguna función de clasificación o categorización. El estándar define cinco clases:

Respuesta informativa 1xx : se recibió la solicitud, el proceso continúa
2xx exitoso : la solicitud se recibió, entendió y aceptó correctamente
Redirección 3xx : se deben tomar medidas adicionales para completar la solicitud
Error de cliente 4xx : la solicitud contiene una sintaxis incorrecta o no se puede completar
Error de servidor 5xx : el servidor no pudo cumplir con una solicitud aparentemente válida

1xx respuesta informativa

Una respuesta informativa indica que la solicitud fue recibida y entendida. Se emite de manera provisoria mientras continúa el procesamiento de la solicitud. Alerta al cliente para que espere una respuesta final. El mensaje consta únicamente de la línea de estado y los campos de encabezado opcionales, y termina con una línea vacía. Como el estándar HTTP/1.0 no definió ningún código de estado 1xx, los servidores no deben ^{[nota 1]} enviar una respuesta 1xx a un cliente compatible con HTTP/1.0 excepto en condiciones experimentales.

100 Continuar: El servidor ha recibido los encabezados de la solicitud y el cliente debe proceder a enviar el cuerpo de la solicitud (en el caso de una solicitud para la que se necesita enviar un cuerpo; por ejemplo, una solicitud POST ). Enviar un cuerpo de solicitud grande a un servidor después de que se haya rechazado una solicitud por encabezados inadecuados sería ineficiente. Para que un servidor verifique los encabezados de la solicitud, un cliente debe enviar Expect: 100-continueun encabezado en su solicitud inicial y recibir un 100 Continuecódigo de estado en respuesta antes de enviar el cuerpo. Si el cliente recibe un código de error como 403 (Prohibido) o 405 (Método no permitido), entonces no debe enviar el cuerpo de la solicitud. La respuesta 417 Expectation Failedindica que la solicitud debe repetirse sin el Expectencabezado, ya que indica que el servidor no admite las expectativas (este es el caso, por ejemplo, de los servidores HTTP/1.0). ^[1]^{: §10.1.1}
101 Protocolos de conmutación: El solicitante ha pedido al servidor que cambie de protocolo y el servidor ha aceptado hacerlo.
102 Procesamiento ( WebDAV ; RFC 2518): Una solicitud WebDAV puede contener muchas subsolicitudes que involucran operaciones de archivos, lo que requiere mucho tiempo para completar la solicitud. Este código indica que el servidor recibió y está procesando la solicitud, pero que aún no hay una respuesta disponible. ^[3] Esto evita que el cliente agote el tiempo de espera y suponga que la solicitud se perdió. El código de estado está obsoleto. ^[4]
103 Consejos tempranos (RFC 8297): Se utiliza para devolver algunos encabezados de respuesta antes del mensaje HTTP final. ^[5]

2xx éxito

Esta clase de códigos de estado indica que la acción solicitada por el cliente fue recibida, entendida y aceptada. ^[2]

200 OK: Respuesta estándar para solicitudes HTTP exitosas. La respuesta real dependerá del método de solicitud utilizado. En una solicitud GET, la respuesta contendrá una entidad correspondiente al recurso solicitado. En una solicitud POST, la respuesta contendrá una entidad que describa o contenga el resultado de la acción.
201 Creado: La solicitud se ha cumplido, dando como resultado la creación de un nuevo recurso. ^[6]
202 Aceptado: La solicitud ha sido aceptada para su tramitación, pero el procesamiento no ha finalizado. Es posible que se dé curso a la solicitud o que no, y que se desestime cuando se procese.
203 Información no autorizada (desde HTTP/1.1): El servidor es un proxy transformador (por ejemplo, un acelerador web ) que recibió un 200 OK de su origen, pero está devolviendo una versión modificada de la respuesta del origen. ^[1]^{: §15.3.4}^[1]^{: §7.7}
204 Sin contenido: El servidor procesó exitosamente la solicitud y no devuelve ningún contenido.
205 Restablecer contenido: El servidor procesó exitosamente la solicitud, pide al solicitante que restablezca su vista del documento y no devuelve ningún contenido.
206 Contenido parcial: El servidor entrega solo una parte del recurso ( entrega de bytes ) debido a un encabezado de rango enviado por el cliente. Los clientes HTTP utilizan el encabezado de rango para permitir la reanudación de descargas interrumpidas o dividir una descarga en múltiples transmisiones simultáneas.
207 Multiestado (WebDAV; RFC 4918): El cuerpo del mensaje que sigue es por defecto un mensaje XML y puede contener varios códigos de respuesta separados, dependiendo de cuántas subsolicitudes se hayan realizado. ^[7]
208 ya informado (WebDAV; RFC 5842): Los miembros de un enlace DAV ya se han enumerado en una parte anterior de la respuesta (multiestado) y no se vuelven a incluir.
226 IM utilizado (RFC 3229): El servidor ha cumplido una solicitud del recurso y la respuesta es una representación del resultado de una o más manipulaciones de instancia aplicadas a la instancia actual. ^[8]

Redirección 3xx

Esta clase de código de estado indica que el cliente debe realizar una acción adicional para completar la solicitud. Muchos de estos códigos de estado se utilizan en la redirección de URL . ^[2]

Un agente de usuario puede llevar a cabo la acción adicional sin interacción del usuario solo si el método utilizado en la segunda solicitud es GET o HEAD. Un agente de usuario puede redirigir automáticamente una solicitud. Un agente de usuario debe detectar e intervenir para evitar redirecciones cíclicas. ^[1]^{: §15.4}

300 opciones múltiples: Indica múltiples opciones para el recurso entre las cuales el cliente puede elegir (a través de la negociación de contenido impulsada por el agente ). Por ejemplo, este código podría usarse para presentar múltiples opciones de formato de video, para enumerar archivos con diferentes extensiones de nombre de archivo o para sugerir la desambiguación del sentido de las palabras .
301 se trasladó de forma permanente: Esta y todas las solicitudes futuras deben dirigirse a la URI indicada .
302 encontrados (anteriormente "movidos temporalmente"): Indica al cliente que mire (busque) otra URL. La especificación HTTP/1.0 requería que el cliente realizara una redirección temporal con el mismo método (la frase descriptiva original era "Moved Temporarily"), ^[9] pero los navegadores populares implementaron redirecciones 302 cambiando el método a GET. Por lo tanto, HTTP/1.1 agregó los códigos de estado 303 y 307 para distinguir entre los dos comportamientos. ^[1]^{: §15.4}
303 Ver Otros (desde HTTP/1.1): La respuesta a la solicitud se puede encontrar en otra URI mediante el método GET. Cuando se recibe en respuesta a un POST (o PUT/DELETE), el cliente debe suponer que el servidor ha recibido los datos y debe emitir una nueva solicitud GET a la URI indicada.
304 No modificado: Indica que el recurso no ha sido modificado desde la versión especificada en los encabezados de solicitud If-Modified-Since o If-None-Match. En tal caso, no es necesario volver a transmitir el recurso, ya que el cliente aún tiene una copia descargada previamente.
305 Usar proxy (desde HTTP/1.1): El recurso solicitado está disponible únicamente a través de un proxy, cuya dirección se proporciona en la respuesta. Por razones de seguridad, muchos clientes HTTP (como Mozilla Firefox e Internet Explorer ) no obedecen este código de estado. ^[10]
306 Cambiar proxy: Ya no se utiliza. Originalmente significaba "Las solicitudes posteriores deben utilizar el proxy especificado".
307 Redirección temporal (desde HTTP/1.1): En este caso, la solicitud debe repetirse con otra URI; sin embargo, las solicitudes futuras deben seguir utilizando la URI original. A diferencia de cómo se implementaba históricamente la regla 302, no se permite cambiar el método de solicitud al volver a emitir la solicitud original. Por ejemplo, una solicitud POST debe repetirse utilizando otra solicitud POST.
308 Redirección permanente: Esta y todas las solicitudes futuras deben dirigirse a la URL indicada . El procedimiento 308 es similar al procedimiento 301, pero no permite que el método HTTP cambie . Por lo tanto, por ejemplo, el envío de un formulario a un recurso redirigido permanentemente puede continuar sin problemas.

Errores de cliente 4xx

Esta clase de código de estado está pensada para situaciones en las que el error parece haber sido causado por el cliente. Excepto cuando se responde a una solicitud HEAD, el servidor debe incluir una entidad que contenga una explicación de la situación de error y si se trata de una condición temporal o permanente. Estos códigos de estado son aplicables a cualquier método de solicitud . Los agentes de usuario deben mostrar al usuario cualquier entidad incluida.

400 Solicitud incorrecta: El servidor no puede o no quiere procesar la solicitud debido a un error aparente del cliente (por ejemplo, sintaxis de solicitud mal formada, tamaño demasiado grande, estructura de mensaje de solicitud no válida o enrutamiento de solicitud engañoso).
401 No autorizado: Similar a 403 Forbidden, pero específicamente para usarse cuando se requiere autenticación y ha fallado o aún no se ha proporcionado. La respuesta debe incluir un campo de encabezado WWW-Authenticate que contenga un desafío aplicable al recurso solicitado. Consulte Autenticación de acceso básica y Autenticación de acceso Digest . 401 significa semánticamente "no autenticado", el usuario no tiene credenciales de autenticación válidas para el recurso de destino.
Pago 402 requerido: Reservado para uso futuro. La intención original era que este código pudiera usarse como parte de alguna forma de dinero digital o esquema de micropagos , como lo propuso, por ejemplo, GNU Taler , ^[11] pero eso aún no ha sucedido, y este código no se usa ampliamente. Google Developers API usa este estado si un desarrollador en particular ha excedido el límite diario de solicitudes. ^[12] Sipgate usa este código si una cuenta no tiene fondos suficientes para iniciar una llamada. ^[13] Shopify usa este código cuando la tienda no ha pagado sus tarifas y está deshabilitada temporalmente. ^[14] Stripe usa este código para pagos fallidos donde los parámetros eran correctos, por ejemplo, pagos fraudulentos bloqueados. ^[15]
403 Prohibido: La solicitud contenía datos válidos y el servidor la entendió, pero el servidor rechaza la acción. Esto puede deberse a que el usuario no tiene los permisos necesarios para un recurso o necesita una cuenta de algún tipo, o intenta una acción prohibida (por ejemplo, crear un registro duplicado cuando solo se permite uno). Este código también se usa normalmente si la solicitud proporcionó autenticación al responder al desafío del campo de encabezado WWW-Authenticate, pero el servidor no aceptó esa autenticación. La solicitud no debe repetirse.
404 No encontrado: No se pudo encontrar el recurso solicitado, pero es posible que esté disponible en el futuro. Se permiten solicitudes posteriores por parte del cliente.
Método 405 no permitido: No se admite un método de solicitud para el recurso solicitado; por ejemplo, una solicitud GET en un formulario que requiere que los datos se presenten mediante POST o una solicitud PUT en un recurso de solo lectura.
406 No aceptable: El recurso solicitado es capaz de generar únicamente contenido no aceptable según los encabezados Accept enviados en la solicitud. Ver Negociación de contenido .
407 Se requiere autenticación de proxy: El cliente debe primero autenticarse con el proxy .
408 Tiempo de espera de solicitud agotado: El servidor agotó el tiempo de espera de la solicitud. Según las especificaciones HTTP: "El cliente no produjo una solicitud dentro del tiempo que el servidor estaba preparado para esperar. El cliente PUEDE repetir la solicitud sin modificaciones en cualquier momento posterior".
409 Conflict: Indica que no se pudo procesar la solicitud debido a un conflicto en el estado actual del recurso, como un conflicto de edición entre múltiples actualizaciones simultáneas.
410 desaparecido: Indica que el recurso solicitado se utilizó anteriormente, pero ya no está disponible y no volverá a estarlo. Esto se debe utilizar cuando se ha eliminado intencionalmente un recurso y se debe purgar. Al recibir un código de estado 410, el cliente no debe solicitar el recurso en el futuro. Los clientes, como los motores de búsqueda, deben eliminar el recurso de sus índices. La mayoría de los casos de uso no requieren que los clientes y los motores de búsqueda purguen el recurso, y se puede utilizar un "404 No encontrado" en su lugar.
411 Longitud requerida: La solicitud no especificó la longitud de su contenido, que es requerida por el recurso solicitado.
412 Condición previa fallida: El servidor no cumple una de las condiciones previas que el solicitante puso en los campos del encabezado de la solicitud.
413 Carga útil demasiado grande: La solicitud es más grande de lo que el servidor está dispuesto o puede procesar. Anteriormente se denominaba "Entidad de solicitud demasiado grande". ^[16]^{: §10.4.14}
414 URI demasiado larga: La URI proporcionada era demasiado larga para que el servidor la procesara. A menudo, esto se debe a que se codificaron demasiados datos como una cadena de consulta de una solicitud GET, en cuyo caso se deben convertir en una solicitud POST. Anteriormente se denominaba "URI de solicitud demasiado larga". ^[16]^{: §10.4.15}
415 Tipo de medio no compatible: La entidad de solicitud tiene un tipo de medio que el servidor o el recurso no admiten. Por ejemplo, el cliente carga una imagen como image/svg+xml , pero el servidor requiere que las imágenes utilicen un formato diferente.
416 Rango no satisfactorio: El cliente ha solicitado una parte del archivo ( byte serving ), pero el servidor no puede proporcionar esa parte. Por ejemplo, si el cliente solicitó una parte del archivo que se encuentra más allá del final del archivo. Anteriormente se denominaba "Rango solicitado no satisfacible". ^[16]^{: §10.4.17}
417 Expectativa fallida: El servidor no puede cumplir con los requisitos del campo de encabezado de solicitud Expect. ^[17]
418 Soy una tetera (RFC 2324, RFC 7168): Este código se definió en 1998 como una de las bromas tradicionales del Día de los Inocentes de la IETF , en el RFC 2324, Hyper Text Coffee Pot Control Protocol , y no se espera que sea implementado por servidores HTTP reales. El RFC especifica que este código debe ser devuelto por teteras a las que se les solicita que preparen café. ^[18] Este estado HTTP se utiliza como un huevo de Pascua en algunos sitios web, como el huevo de Pascua "Soy una tetera" de Google.com . ^[19]^[20]^[21] A veces, este código de estado también se utiliza como respuesta a una solicitud bloqueada, en lugar del más apropiado 403 Forbidden. ^[22]^[23]
421 Solicitud mal dirigida: La solicitud fue dirigida a un servidor que no puede producir una respuesta (por ejemplo, debido a la reutilización de la conexión).
422 Contenido no procesable: La solicitud estaba bien formulada (es decir, sintácticamente correcta) pero no se pudo procesar. ^[1]^{: §15.5.21}
423 Bloqueado (WebDAV; RFC 4918): El recurso al que se está accediendo está bloqueado. ^[7]
424 Dependencia fallida (WebDAV; RFC 4918): La solicitud falló porque dependía de otra solicitud y esa solicitud falló (por ejemplo, un PROPPATCH). ^[7]
425 Demasiado pronto (RFC 8470): Indica que el servidor no está dispuesto a correr el riesgo de procesar una solicitud que pueda reproducirse.
426 Se requiere actualización: El cliente debe cambiar a un protocolo diferente, como TLS/1.3 , que figura en el campo de encabezado Actualización .
428 Condición previa requerida (RFC 6585): El servidor de origen requiere que la solicitud sea condicional. Esto tiene como objetivo evitar el problema de la "actualización perdida", en el que un cliente obtiene el estado de un recurso, lo modifica y lo devuelve al servidor, mientras que un tercero ha modificado el estado en el servidor, lo que genera un conflicto. ^[24]
429 Demasiadas solicitudes (RFC 6585): El usuario ha enviado demasiadas solicitudes en un período de tiempo determinado. Destinado a utilizarse con esquemas de limitación de velocidad . ^[24]
431 Los campos del encabezado de solicitud son demasiado grandes (RFC 6585): El servidor no está dispuesto a procesar la solicitud porque un campo de encabezado individual o todos los campos de encabezado en conjunto son demasiado grandes. ^[24]
451 No disponible por razones legales (RFC 7725): Un operador de servidor ha recibido una demanda legal para denegar el acceso a un recurso o a un conjunto de recursos que incluye el recurso solicitado. ^[25] El código 451 fue elegido como referencia a la novela Fahrenheit 451 (ver los Agradecimientos en el RFC).

Errores del servidor 5xx

El servidor no pudo cumplir una solicitud.

Los códigos de estado de respuesta que comienzan con el dígito "5" indican casos en los que el servidor es consciente de que ha encontrado un error o de que no puede realizar la solicitud. Excepto cuando se responde a una solicitud HEAD, el servidor debe incluir una entidad que contenga una explicación de la situación de error e indicar si se trata de una condición temporal o permanente. Del mismo modo, los agentes de usuario deben mostrar al usuario cualquier entidad incluida. Estos códigos de respuesta son aplicables a cualquier método de solicitud .

Error interno del servidor 500: Un mensaje de error genérico que aparece cuando se encuentra una condición inesperada y no es adecuado ningún mensaje más específico.
501 No implementado: El servidor no reconoce el método de solicitud o no tiene la capacidad de cumplir con la solicitud. Generalmente, esto implica una disponibilidad futura (por ejemplo, una nueva característica de una API de servicio web).
502 Puerta de enlace no válida: El servidor estaba actuando como puerta de enlace o proxy y recibió una respuesta no válida del servidor ascendente.
503 Servicio no disponible: El servidor no puede procesar la solicitud (porque está sobrecargado o fuera de servicio por mantenimiento). Generalmente, se trata de un estado temporal. ^[26]
504 Tiempo de espera de la puerta de enlace: El servidor estaba actuando como puerta de enlace o proxy y no recibió una respuesta oportuna del servidor ascendente.
505 Versión HTTP no compatible: El servidor no admite la versión HTTP utilizada en la solicitud.
La variante 506 también se negocia (RFC 2295): La negociación de contenido transparente para la solicitud da como resultado una referencia circular . ^[27]
507 Almacenamiento insuficiente (WebDAV; RFC 4918): El servidor no puede almacenar la representación necesaria para completar la solicitud. ^[7]
508 Bucle detectado (WebDAV; RFC 5842): El servidor detectó un bucle infinito mientras procesaba la solicitud (enviada en lugar de 208 Ya informado).
510 No extendido (RFC 2774): Se requieren extensiones adicionales a la solicitud para que el servidor la cumpla. ^[28]
511 Se requiere autenticación de red (RFC 6585): El cliente debe autenticarse para obtener acceso a la red. Está pensado para ser utilizado para interceptar servidores proxy utilizados para controlar el acceso a la red (por ejemplo, " portales cautivos " utilizados para exigir la aceptación de los Términos de servicio antes de otorgar acceso total a Internet a través de un punto de acceso Wi-Fi ). ^[24]

Códigos no oficiales

Los siguientes códigos no están especificados por ninguna norma.

218 Esto está bien ( Servidor HTTP Apache ): Utilizado por servidores Apache. Es una condición de error general que permite el paso de cuerpos de mensajes a través del servidor cuando la ProxyErrorOverride configuración está habilitada. Se muestra en esta situación en lugar de un mensaje de error 4xx o 5xx. ^[29]
Página 419 caducada ( Laravel Framework): Utilizado por el Framework Laravel cuando falta un token CSRF o está vencido. ^[30]
Error de método 420 ( Spring Framework ): Un estado de respuesta obsoleto propuesto durante el desarrollo de WebDAV ^[31] utilizado por Spring Framework cuando un método ha fallado. ^[32]
420 Mejora tu calma ( Twitter ): Devuelto por la versión 1 de la API de búsqueda y tendencias de Twitter cuando el cliente está sujeto a una limitación de velocidad; las versiones 1.1 y posteriores utilizan el código de respuesta 429 Too Many Requests en su lugar. ^[33] La frase "Enhance your calm" (Mejora tu calma) proviene de la película Demolition Man de 1993 , y su asociación con este número probablemente sea una referencia al cannabis . ^{[ cita requerida ]}
430 Los campos del encabezado de solicitud son demasiado grandes ( Shopify ): Una respuesta obsoleta utilizada por Shopify , en lugar del código de respuesta 429 Too Many Requests, cuando se solicitan demasiadas URL dentro de un período de tiempo determinado. ^[34]
430 Rechazo de seguridad de Shopify ( Shopify ): Shopify lo utiliza para indicar que la solicitud se consideró maliciosa. ^[35]
450 Bloqueado por el Control parental de Windows (Microsoft): El código de extensión de Microsoft indica cuándo los controles parentales de Windows están activados y bloquean el acceso a la página web solicitada. ^[36]
498 Token no válido (Esri): Devuelto por ArcGIS for Server . El código 498 indica un token vencido o no válido. ^[37]
Se requiere token 499 (Esri): Devuelto por ArcGIS for Server . El código 499 indica que se requiere un token pero no se envió. ^[37]
509 Se ha excedido el límite de ancho de banda ( servidor web Apache / cPanel ): El servidor ha excedido el ancho de banda especificado por el administrador del servidor; los proveedores de alojamiento compartido suelen utilizar esto para limitar el ancho de banda de los clientes. ^[38]
529 El sitio está sobrecargado: Utilizado por Qualys en la API de pruebas del servidor SSLLabs para señalar que el sitio no puede procesar la solicitud. ^[39]
530 El sitio está congelado: Utilizado por la plataforma web Pantheon Systems para indicar un sitio que ha sido congelado debido a la inactividad. ^[40]
Error de DNS de origen 530 ( Shopify ): Utilizado por Shopify para indicar que Cloudflare no puede resolver el registro DNS solicitado. ^[35]
540 Desactivado temporalmente ( Shopify ): Shopify lo utiliza para indicar que el punto final solicitado se ha deshabilitado temporalmente. ^[35]
598 (Convención informal) Error de tiempo de espera de lectura de red: Utilizado por algunos servidores proxy HTTP para señalar un tiempo de espera de lectura de red detrás del proxy a un cliente frente al proxy. ^[41]
599 Error de tiempo de espera de conexión de red: Un error utilizado por algunos servidores proxy HTTP para señalar un tiempo de espera de conexión de red detrás del proxy a un cliente delante del proxy.
783 Token inesperado ( Shopify ): Utilizado por Shopify para indicar que la solicitud incluye un error de sintaxis JSON. ^[35]
999 No estándar: LinkedIn utiliza el error 999 y está relacionado con el bloqueo/amurallamiento o la imposibilidad de acceder a sus páginas web sin iniciar sesión primero. ^[42]

Servicios de información de Internet

El servidor web de Internet Information Services (IIS) de Microsoft amplía el espacio de error 4xx para señalar errores con la solicitud del cliente.

440 Tiempo de espera de inicio de sesión agotado: La sesión del cliente ha expirado y debe iniciar sesión nuevamente. ^[43]
449 Reintentar con: El servidor no puede atender la solicitud porque el usuario no ha proporcionado la información requerida. ^[44]
Redirección 451: Se utiliza en Exchange ActiveSync cuando hay un servidor más eficiente disponible o el servidor no puede acceder al buzón de los usuarios. ^[45] Se espera que el cliente vuelva a ejecutar la operación HTTP AutoDiscover para encontrar un servidor más apropiado. ^[46]

IIS a veces utiliza subcódigos decimales adicionales para obtener información más específica, ^[47] sin embargo, estos subcódigos solo aparecen en la carga de respuesta y en la documentación, no en lugar de un código de estado HTTP real.

nginx

El software del servidor web nginx amplía el espacio de error 4xx para señalar problemas con la solicitud del cliente. ^[48]^[49]

444 Sin respuesta: Se utiliza internamente ^[50] para indicar al servidor que no devuelva ninguna información al cliente y cierre la conexión inmediatamente.
494 El encabezado de solicitud es demasiado grande: El cliente envió una solicitud demasiado grande o una línea de encabezado demasiado larga.
Error 495 del certificado SSL: Una expansión del código de respuesta 400 Bad Request, que se utiliza cuando el cliente ha proporcionado un certificado de cliente no válido .
496 Se requiere certificado SSL: Una expansión del código de respuesta 400 Bad Request, que se utiliza cuando se requiere un certificado de cliente pero no se proporciona.
Solicitud HTTP 497 enviada al puerto HTTPS: Una expansión del código de respuesta 400 Bad Request, que se utiliza cuando el cliente ha realizado una solicitud HTTP a un puerto que escucha solicitudes HTTPS.
499 Solicitud cerrada del cliente: Se utiliza cuando el cliente ha cerrado la solicitud antes de que el servidor pueda enviar una respuesta.

Nube de llamas

El servicio de proxy inverso de Cloudflare amplía el espacio de errores de la serie 5xx para señalar problemas con el servidor de origen. ^[51]

520 El servidor web devolvió un error desconocido: El servidor de origen devolvió una respuesta vacía, desconocida o inesperada a Cloudflare. ^[52]
521 El servidor web está inactivo: El servidor de origen rechazó las conexiones de Cloudflare. Las soluciones de seguridad del servidor de origen pueden estar bloqueando conexiones legítimas desde determinadas direcciones IP de Cloudflare.
522 Tiempo de conexión agotado: Se agotó el tiempo de conexión de Cloudflare con el servidor de origen.
523 El origen es inalcanzable: Cloudflare no pudo comunicarse con el servidor de origen; por ejemplo, si los registros DNS del servidor de origen son incorrectos o faltan.
524 Se agotó el tiempo de espera: Cloudflare pudo completar una conexión TCP con el servidor de origen, pero no recibió una respuesta HTTP oportuna.
525 Fallo en el protocolo de enlace SSL: Cloudflare no pudo negociar un protocolo de enlace SSL/TLS con el servidor de origen.
526 Certificado SSL no válido: Cloudflare no pudo validar el certificado SSL en el servidor web de origen. También lo utiliza el enrutador de Cloud Foundry .
Error del cañón de riel 527 (obsoleto): El error 527 indicó una conexión interrumpida entre Cloudflare y el servidor Railgun del servidor de origen. ^[53] Este error está obsoleto ya que Cloudflare ha dejado obsoleto Railgun.
530: Se devuelve el error 530 junto con un error 1xxx. ^[54]

Equilibrio de carga elástico de AWS

Elastic Load Balancing de Amazon Web Services agrega algunos códigos de retorno personalizados para señalar problemas con la solicitud del cliente o con el servidor de origen. ^[55]

000: Se devuelve con un marco GOAWAY HTTP/2 si la longitud comprimida de cualquiera de los encabezados supera los 8 000 bytes o si se atienden más de 10 000 solicitudes a través de una conexión. ^[55]
460: El cliente cerró la conexión con el balanceador de carga antes de que transcurriera el período de inactividad. Normalmente, el tiempo de espera del cliente es anterior al tiempo de espera del balanceador de carga elástico. ^[55]
463: El equilibrador de carga recibió un encabezado de solicitud X-Forwarded-For con más de 30 direcciones IP. ^[55]
464: Versiones de protocolo incompatibles entre el cliente y el servidor de origen. ^[55]
561 No autorizado: Un servidor registrado con un balanceador de carga devolvió un error relacionado con la autenticación. Se configuró una regla de escucha para autenticar a los usuarios, pero el proveedor de identidad (IdP) devolvió un código de error al autenticar al usuario. ^[55]

Códigos de advertencia de almacenamiento en caché (obsoletos)

Los siguientes códigos de advertencia relacionados con el almacenamiento en caché se especificaron en RFC 7234. A diferencia de los otros códigos de estado anteriores, estos no se enviaron como estado de respuesta en el protocolo HTTP, sino como parte del encabezado HTTP "Advertencia". ^[56]^[57]

Dado que este encabezado de "Advertencia" a menudo no lo envían los servidores ni lo reconocen los clientes, este encabezado y sus códigos quedaron obsoletos por el Grupo de Trabajo HTTP en 2022 con RFC 9111. ^[58]

110 La respuesta está obsoleta: La respuesta proporcionada por un caché está obsoleta (la edad del contenido excede una edad máxima establecida por un encabezado Cache-Control o una vida útil elegida heurísticamente).
111 Revalidación fallida: La caché no pudo validar la respuesta debido a la imposibilidad de comunicarse con el servidor de origen.
112 Operación Desconectada: La caché se desconecta intencionalmente del resto de la red.
113 Expiración heurística: La caché eligió heurísticamente un tiempo de frescura mayor a 24 horas y la antigüedad de la respuesta es mayor a 24 horas.
199 Advertencias varias: Advertencia arbitraria y no específica. El texto de advertencia puede registrarse o mostrarse al usuario.
214 Transformación aplicada: Lo agrega un proxy si aplica alguna transformación a la representación, como cambiar la codificación del contenido, el tipo de medio o similar.
299 Advertencia persistente miscelánea: Igual que 199, pero indica una advertencia persistente.

Véase también

Notas

^ Las palabras y frases enfatizadas como must y should representan pautas de interpretación según lo establecido en RFC 2119

Referencias

^ abcdefg R. Fielding ; M. Nottingham; J. Reschke, eds. (junio de 2022). Semántica HTTP. Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC9110 . ISSN 2070-1721. STD 97. RFC 9110. Estándar de Internet 97. Deja obsoletos los RFC 2818, 7230, 7231, 7232, 7233, 7235, 7538, 7615 y 7694. Actualiza el RFC 3864.
^ abc «Hypertext Transfer Protocol (HTTP) Status Code Registry» (Registro de código de estado del protocolo de transferencia de hipertexto [HTTP]). Iana.org. Archivado desde el original el 11 de diciembre de 2011. Consultado el 8 de enero de 2015 .
^ Goland, Yaronn; Whitehead, Jim ; Faizi, Asad; Carter, Steve R.; Jensen, Del (febrero de 1999). Extensiones HTTP para creación distribuida – WEBDAV. Grupo de trabajo de redes. doi : 10.17487/RFC2518 . RFC 2518. Norma propuesta. Quedó obsoleta a partir de la RFC 4918.
^ "Procesamiento 102: HTTP MDN". 25 de julio de 2023.El código de estado 102 está obsoleto
^ Oku, Kazuho (diciembre de 2017). Un código de estado HTTP para indicar sugerencias. IETF . doi : 10.17487/RFC8297 . RFC 8297. Experimental.
^ Stewart, Mark; djna. "Crear una solicitud con POST, cuyos códigos de respuesta sean 200 o 201 y contenido". Desbordamiento de pila . Archivado desde el original el 11 de octubre de 2016 . Consultado el 16 de octubre de 2015 .
^ abcd Dusseault, Lisa, ed. (junio de 2007). Extensiones HTTP para creación y control de versiones distribuidos en la Web (WebDAV). Grupo de trabajo en red. doi : 10.17487/RFC4918 . RFC 4918. Norma propuesta. Actualizada por RFC 5689. Deja obsoleta la RFC 2518.
^ Hoff, Arthur van ; Douglis, Fred; Krishnamurthy, Balachander; Goland, Yaron Y.; Hellerstein, Daniel M.; Feldmann, Anja; Mogul, Jeffrey (enero de 2002). Codificación delta en HTTP. Grupo de trabajo de redes. doi : 10.17487/RFC3229 . RFC 3229. Norma propuesta.
^ T. Berners-Lee ; R. Fielding ; H. Frystyk (mayo de 1996). Protocolo de transferencia de hipertexto -- HTTP/1.0. Grupo de trabajo de redes. doi : 10.17487/RFC1945 . RFC 1945. Informativo.
^ "Mozilla Bugzilla Bug 187996: comportamiento extraño en la redirección 305, comentario 13". 3 de marzo de 2003. Archivado desde el original el 21 de abril de 2014. Consultado el 21 de mayo de 2009 .
^ "El tutorial de GNU Taler para desarrolladores de tiendas web PHP 0.4.0". docs.taler.net . Archivado desde el original el 8 de noviembre de 2017 . Consultado el 29 de octubre de 2017 .
^ "Respuestas de error estándar de la API de Google". 2016. Archivado desde el original el 25 de mayo de 2017. Consultado el 21 de junio de 2017 .
^ "Documentación de la API de Sipgate". Archivado desde el original el 10 de julio de 2018 . Consultado el 10 de julio de 2018 .
^ "Documentación de Shopify". Archivado desde el original el 25 de julio de 2018 . Consultado el 25 de julio de 2018 .
^ "Referencia de la API de Stripe: errores". stripe.com . Consultado el 28 de octubre de 2019 .
^ abc R. Fielding ; J. Gettys; J. Mogul; H. Frystyk ; L. Masinter ; P. Leach; T. Berners-Lee (agosto de 1999). Protocolo de transferencia de hipertexto -- HTTP/1.1. Grupo de trabajo de redes. doi : 10.17487/RFC2616 . RFC 2616. Obsoleto. Quedó obsoleto según RFC 7230, 7231, 7232, 7233, 7234 y 7235. Quedó obsoleto según RFC 2068. Actualizado según RFC 2817, 5785, 6266 y 6585.
^ TheDeadLike. «Códigos de estado HTTP/1.1 400 y 417, no se puede elegir cuál». serverFault . Archivado desde el original el 10 de octubre de 2015 . Consultado el 16 de octubre de 2015 .
^ L. Masinter (1 de abril de 1998). Protocolo de control de cafeteras de hipertexto (HTCPCP/1.0). Grupo de trabajo de redes. doi : 10.17487/RFC2324 . RFC 2324. Informativo. Actualizado por RFC 7168. Esta es una solicitud de comentarios por el Día de los Inocentes . Cualquier intento de preparar café con una tetera debería generar el código de error "418 Soy una tetera". El cuerpo de la entidad resultante PUEDE ser breve y robusto.
^ Soy una tetera
^ Barry Schwartz (26 de agosto de 2014). «Nuevo huevo de Pascua de Google para expertos en SEO: estado del servidor 418, soy una tetera». Search Engine Land . Archivado desde el original el 15 de noviembre de 2015. Consultado el 4 de noviembre de 2015 .
^ "La tetera de Google" . Consultado el 23 de octubre de 2017 .
^ "Habilitar seguridad web adicional en un sitio web". DreamHost . Consultado el 18 de diciembre de 2022 .
^ "Fui a un sitio web ruso y lo único que encontré fue esta tetera de mala calidad". PCMag . Consultado el 18 de diciembre de 2022 .
^ abcd M. Nottingham; R. Fielding (abril de 2012). Códigos de estado HTTP adicionales. Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC6585 . ISSN 2070-1721. RFC 6585. Norma propuesta. Actualizaciones RFC 2616.
^ Bray, T. (febrero de 2016). "Un código de estado HTTP para informar sobre obstáculos legales". ietf.org . Archivado desde el original el 4 de marzo de 2016. Consultado el 7 de marzo de 2015 .
^ alex. "¿Cuál es el código de estado HTTP correcto que se debe enviar cuando un sitio está inactivo por mantenimiento?". Stack Overflow . Archivado desde el original el 11 de octubre de 2016. Consultado el 16 de octubre de 2015 .
^ Holtman, Koen; Mutz, Andrew H. (marzo de 1998). Negociación de contenido transparente en HTTP. Grupo de trabajo de redes. doi : 10.17487/RFC2295 . RFC 2295. Experimental.
^ Nielsen, Henrik Frystyk ; Leach, Paul; Lawrence, Scott (febrero de 2000). Un marco de extensión HTTP. Grupo de trabajo de redes. doi : 10.17487/RFC2774 . RFC 2774. Histórico.
^ "218 Esto está bien: código de estado HTTP explicado". HTTP.dev . Consultado el 25 de julio de 2023 .
^ "framework/src/Illuminate/Foundation/Exceptions/Handler.php". GitHub . Consultado el 12 de diciembre de 2023 .
^ "draft-ietf-webdav-protocol-05: Extensiones para creación distribuida en la World Wide Web -- WEBDAV".
^ "Enum HttpStatus". Spring Framework . org.springframework.http. Archivado desde el original el 25 de octubre de 2015 . Consultado el 16 de octubre de 2015 .
^ "Códigos de error y respuestas de Twitter". Twitter . 2014. Archivado desde el original el 27 de septiembre de 2017 . Consultado el 20 de enero de 2014 .
^ "Códigos de estado HTTP y SEO: lo que necesitas saber". ContentKing . Consultado el 9 de agosto de 2019 .
^ abcd «Estado de respuesta y códigos de error de la API de Shopify» . Consultado el 12 de diciembre de 2023 .
^ "Captura de pantalla de la página de error". Archivado desde el original (bmp) el 11 de mayo de 2013. Consultado el 11 de octubre de 2009 .
^ ab "Uso de autenticación basada en token". ArcGIS Server SOAP SDK . Archivado desde el original el 26 de septiembre de 2014 . Consultado el 8 de septiembre de 2014 .
^ "Códigos de error HTTP y soluciones rápidas". Docs.cpanel.net. Archivado desde el original el 23 de noviembre de 2015. Consultado el 15 de octubre de 2015 .
^ "Documentación de la API v3 de SSL Labs". github.com .
^ "Consideraciones sobre la plataforma | Pantheon Docs". pantheon.io . Archivado desde el original el 6 de enero de 2017 . Consultado el 5 de enero de 2017 .
^ "Códigos de estado HTTP – ascii-code.com". www.ascii-code.com . Archivado desde el original el 7 de enero de 2017 . Consultado el 23 de diciembre de 2016 .
^ Visto en el ejemplo de 2017 + 2024
^ "Mensaje de error al intentar iniciar sesión en Exchange 2007 mediante Outlook Web Access: "440 Tiempo de espera de inicio de sesión agotado"". Microsoft . 2010 . Consultado el 13 de noviembre de 2013 .
^ "2.2.6 449 Reintentar con código de estado". Microsoft . 2009. Archivado desde el original el 5 de octubre de 2009 . Consultado el 26 de octubre de 2009 .
^ "MS-ASCMD, Sección 3.1.5.2.2". Msdn.microsoft.com. Archivado desde el original el 26 de marzo de 2015. Consultado el 8 de enero de 2015 .
^ "Ms-oxdisco". Msdn.microsoft.com. Archivado desde el original el 31 de julio de 2014. Consultado el 8 de enero de 2015 .
^ "Los códigos de estado HTTP en IIS 7.0". Microsoft . 14 de julio de 2009. Archivado desde el original el 9 de abril de 2009 . Consultado el 1 de abril de 2009 .
^ "ngx_http_request.h". Código fuente de nginx 1.9.5 . nginx inc. Archivado desde el original el 19 de septiembre de 2017 . Consultado el 9 de enero de 2016 .
^ "ngx_http_special_response.c". Código fuente de nginx 1.9.5 . nginx inc. Archivado desde el original el 8 de mayo de 2018 . Consultado el 9 de enero de 2016 .
^ Directiva "return" Archivado el 1 de marzo de 2018 en la documentación de Wayback Machine (módulo http_rewrite).
^ "Solución de problemas: páginas de error". Cloudflare . Archivado desde el original el 4 de marzo de 2016. Consultado el 9 de enero de 2016 .
^ "Error 520: el servidor web devuelve un error desconocido". Cloudflare .
^ "Error 527: Error de origen del receptor Railgun". Cloudflare . Archivado desde el original el 13 de octubre de 2016. Consultado el 12 de octubre de 2016 .
^ "Error 530". Cloudflare . Consultado el 1 de noviembre de 2019 .
^ abcdef "Solucione los problemas de los balanceadores de carga de aplicaciones: Elastic Load Balancing". docs.aws.amazon.com . Consultado el 17 de mayo de 2023 .
^ R. Fielding ; M. Nottingham; J. Reschke (junio de 2014). Protocolo de transferencia de hipertexto (HTTP/1.1): almacenamiento en caché. Grupo de trabajo de ingeniería de Internet (IETF). doi : 10.17487/RFC7234 . RFC 7234. Norma propuesta, sección 5.5. Queda obsoleta por la RFC 9111. Deja obsoleta la RFC 2616.
^ "Advertencia: HTTP | MDN". developer.mozilla.org . Consultado el 15 de agosto de 2021 . Este artículo incorpora texto disponible bajo la licencia CC BY-SA 2.5.
^ "Advertencia". Almacenamiento en caché HTTP. Junio de 2022. Sección 5.5. doi : 10.17487/RFC9111 . RFC 9111.

Enlaces externos

Registro de códigos de estado del Protocolo de transferencia de hipertexto (HTTP) en la Autoridad de números asignados de Internet
Códigos de estado HTTP en http-statuscode.com
Referencia del código de estado de MDN en mozilla.org

[3] Las palabras y frases enfatizadas como must y should representan pautas de interpretación según lo establecido en RFC 2119

[rfc9110-1] R. Fielding ; M. Nottingham; J. Reschke, eds. (junio de 2022). Semántica HTTP. Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC9110 . ISSN 2070-1721. STD 97. RFC 9110. Estándar de Internet 97. Deja obsoletos los RFC 2818, 7230, 7231, 7232, 7233, 7235, 7538, 7615 y 7694. Actualiza el RFC 3864.

[iana_status_codes-2] «Hypertext Transfer Protocol (HTTP) Status Code Registry» (Registro de código de estado del protocolo de transferencia de hipertexto [HTTP]). Iana.org. Archivado desde el original el 11 de diciembre de 2011. Consultado el 8 de enero de 2015 .

[rfc2518-4] Goland, Yaronn; Whitehead, Jim ; Faizi, Asad; Carter, Steve R.; Jensen, Del (febrero de 1999). Extensiones HTTP para creación distribuida – WEBDAV. Grupo de trabajo de redes. doi : 10.17487/RFC2518 . RFC 2518. Norma propuesta. Quedó obsoleta a partir de la RFC 4918.

[5] "Procesamiento 102: HTTP MDN". 25 de julio de 2023.El código de estado 102 está obsoleto

[rfc8297-6] Oku, Kazuho (diciembre de 2017). Un código de estado HTTP para indicar sugerencias. IETF . doi : 10.17487/RFC8297 . RFC 8297. Experimental.

[7] Stewart, Mark; djna. "Crear una solicitud con POST, cuyos códigos de respuesta sean 200 o 201 y contenido". Desbordamiento de pila . Archivado desde el original el 11 de octubre de 2016 . Consultado el 16 de octubre de 2015 .

[rfc4918-8] Dusseault, Lisa, ed. (junio de 2007). Extensiones HTTP para creación y control de versiones distribuidos en la Web (WebDAV). Grupo de trabajo en red. doi : 10.17487/RFC4918 . RFC 4918. Norma propuesta. Actualizada por RFC 5689. Deja obsoleta la RFC 2518.

[rfc3229-9] Hoff, Arthur van ; Douglis, Fred; Krishnamurthy, Balachander; Goland, Yaron Y.; Hellerstein, Daniel M.; Feldmann, Anja; Mogul, Jeffrey (enero de 2002). Codificación delta en HTTP. Grupo de trabajo de redes. doi : 10.17487/RFC3229 . RFC 3229. Norma propuesta.

[rfc1945-10] T. Berners-Lee ; R. Fielding ; H. Frystyk (mayo de 1996). Protocolo de transferencia de hipertexto -- HTTP/1.0. Grupo de trabajo de redes. doi : 10.17487/RFC1945 . RFC 1945. Informativo.

[11] "Mozilla Bugzilla Bug 187996: comportamiento extraño en la redirección 305, comentario 13". 3 de marzo de 2003. Archivado desde el original el 21 de abril de 2014. Consultado el 21 de mayo de 2009 .

[12] "El tutorial de GNU Taler para desarrolladores de tiendas web PHP 0.4.0". docs.taler.net . Archivado desde el original el 8 de noviembre de 2017 . Consultado el 29 de octubre de 2017 .

[13] "Respuestas de error estándar de la API de Google". 2016. Archivado desde el original el 25 de mayo de 2017. Consultado el 21 de junio de 2017 .

[14] "Documentación de la API de Sipgate". Archivado desde el original el 10 de julio de 2018 . Consultado el 10 de julio de 2018 .

[15] "Documentación de Shopify". Archivado desde el original el 25 de julio de 2018 . Consultado el 25 de julio de 2018 .

[16] "Referencia de la API de Stripe: errores". stripe.com . Consultado el 28 de octubre de 2019 .

[rfc2616-17] R. Fielding ; J. Gettys; J. Mogul; H. Frystyk ; L. Masinter ; P. Leach; T. Berners-Lee (agosto de 1999). Protocolo de transferencia de hipertexto -- HTTP/1.1. Grupo de trabajo de redes. doi : 10.17487/RFC2616 . RFC 2616. Obsoleto. Quedó obsoleto según RFC 7230, 7231, 7232, 7233, 7234 y 7235. Quedó obsoleto según RFC 2068. Actualizado según RFC 2817, 5785, 6266 y 6585.

[18] TheDeadLike. «Códigos de estado HTTP/1.1 400 y 417, no se puede elegir cuál». serverFault . Archivado desde el original el 10 de octubre de 2015 . Consultado el 16 de octubre de 2015 .

[9-19] L. Masinter (1 de abril de 1998). Protocolo de control de cafeteras de hipertexto (HTCPCP/1.0). Grupo de trabajo de redes. doi : 10.17487/RFC2324 . RFC 2324. Informativo. Actualizado por RFC 7168. Esta es una solicitud de comentarios por el Día de los Inocentes . Cualquier intento de preparar café con una tetera debería generar el código de error "418 Soy una tetera". El cuerpo de la entidad resultante PUEDE ser breve y robusto.

[20] Soy una tetera

[21] Barry Schwartz (26 de agosto de 2014). «Nuevo huevo de Pascua de Google para expertos en SEO: estado del servidor 418, soy una tetera». Search Engine Land . Archivado desde el original el 15 de noviembre de 2015. Consultado el 4 de noviembre de 2015 .

[22] "La tetera de Google" . Consultado el 23 de octubre de 2017 .

[23] "Habilitar seguridad web adicional en un sitio web". DreamHost . Consultado el 18 de diciembre de 2022 .

[24] "Fui a un sitio web ruso y lo único que encontré fue esta tetera de mala calidad". PCMag . Consultado el 18 de diciembre de 2022 .

[rfc6585-25] M. Nottingham; R. Fielding (abril de 2012). Códigos de estado HTTP adicionales. Grupo de trabajo de ingeniería de Internet . doi : 10.17487/RFC6585 . ISSN 2070-1721. RFC 6585. Norma propuesta. Actualizaciones RFC 2616.

[26] Bray, T. (febrero de 2016). "Un código de estado HTTP para informar sobre obstáculos legales". ietf.org . Archivado desde el original el 4 de marzo de 2016. Consultado el 7 de marzo de 2015 .

[27] x. "¿Cuál es el código de estado HTTP correcto que se debe enviar cuando un sitio está inactivo por mantenimiento?". Stack Overflow . Archivado desde el original el 11 de octubre de 2016. Consultado el 16 de octubre de 2015 .

[rfc2295-28] Holtman, Koen; Mutz, Andrew H. (marzo de 1998). Negociación de contenido transparente en HTTP. Grupo de trabajo de redes. doi : 10.17487/RFC2295 . RFC 2295. Experimental.

[rfc2774-29] Nielsen, Henrik Frystyk ; Leach, Paul; Lawrence, Scott (febrero de 2000). Un marco de extensión HTTP. Grupo de trabajo de redes. doi : 10.17487/RFC2774 . RFC 2774. Histórico.

[30] "218 Esto está bien: código de estado HTTP explicado". HTTP.dev . Consultado el 25 de julio de 2023 .

[31] "framework/src/Illuminate/Foundation/Exceptions/Handler.php". GitHub . Consultado el 12 de diciembre de 2023 .

[32] "draft-ietf-webdav-protocol-05: Extensiones para creación distribuida en la World Wide Web -- WEBDAV".

[33] "Enum HttpStatus". Spring Framework . org.springframework.http. Archivado desde el original el 25 de octubre de 2015 . Consultado el 16 de octubre de 2015 .

[34] "Códigos de error y respuestas de Twitter". Twitter . 2014. Archivado desde el original el 27 de septiembre de 2017 . Consultado el 20 de enero de 2014 .

[35] "Códigos de estado HTTP y SEO: lo que necesitas saber". ContentKing . Consultado el 9 de agosto de 2019 .

[shopify-api-36] «Estado de respuesta y códigos de error de la API de Shopify» . Consultado el 12 de diciembre de 2023 .

[37] "Captura de pantalla de la página de error". Archivado desde el original (bmp) el 11 de mayo de 2013. Consultado el 11 de octubre de 2009 .

[arcgis-38] "Uso de autenticación basada en token". ArcGIS Server SOAP SDK . Archivado desde el original el 26 de septiembre de 2014 . Consultado el 8 de septiembre de 2014 .

[39] "Códigos de error HTTP y soluciones rápidas". Docs.cpanel.net. Archivado desde el original el 23 de noviembre de 2015. Consultado el 15 de octubre de 2015 .

[40] "Documentación de la API v3 de SSL Labs". github.com .

[41] "Consideraciones sobre la plataforma | Pantheon Docs". pantheon.io . Archivado desde el original el 6 de enero de 2017 . Consultado el 5 de enero de 2017 .

[42] "Códigos de estado HTTP – ascii-code.com". www.ascii-code.com . Archivado desde el original el 7 de enero de 2017 . Consultado el 23 de diciembre de 2016 .

[43] Visto en el ejemplo de 2017 + 2024

[44] "Mensaje de error al intentar iniciar sesión en Exchange 2007 mediante Outlook Web Access: "440 Tiempo de espera de inicio de sesión agotado"". Microsoft . 2010 . Consultado el 13 de noviembre de 2013 .

[45] "2.2.6 449 Reintentar con código de estado". Microsoft . 2009. Archivado desde el original el 5 de octubre de 2009 . Consultado el 26 de octubre de 2009 .

[46] "MS-ASCMD, Sección 3.1.5.2.2". Msdn.microsoft.com. Archivado desde el original el 26 de marzo de 2015. Consultado el 8 de enero de 2015 .

[47] "Ms-oxdisco". Msdn.microsoft.com. Archivado desde el original el 31 de julio de 2014. Consultado el 8 de enero de 2015 .

[48] "Los códigos de estado HTTP en IIS 7.0". Microsoft . 14 de julio de 2009. Archivado desde el original el 9 de abril de 2009 . Consultado el 1 de abril de 2009 .

[49] "ngx_http_request.h". Código fuente de nginx 1.9.5 . nginx inc. Archivado desde el original el 19 de septiembre de 2017 . Consultado el 9 de enero de 2016 .

[50] "ngx_http_special_response.c". Código fuente de nginx 1.9.5 . nginx inc. Archivado desde el original el 8 de mayo de 2018 . Consultado el 9 de enero de 2016 .

[51] Directiva "return" Archivado el 1 de marzo de 2018 en la documentación de Wayback Machine (módulo http_rewrite).

[52] "Solución de problemas: páginas de error". Cloudflare . Archivado desde el original el 4 de marzo de 2016. Consultado el 9 de enero de 2016 .

[53] "Error 520: el servidor web devuelve un error desconocido". Cloudflare .

[54] "Error 527: Error de origen del receptor Railgun". Cloudflare . Archivado desde el original el 13 de octubre de 2016. Consultado el 12 de octubre de 2016 .

[55] "Error 530". Cloudflare . Consultado el 1 de noviembre de 2019 .

[aws.amazon.com-56] "Solucione los problemas de los balanceadores de carga de aplicaciones: Elastic Load Balancing". docs.aws.amazon.com . Consultado el 17 de mayo de 2023 .

[41-57] R. Fielding ; M. Nottingham; J. Reschke (junio de 2014). Protocolo de transferencia de hipertexto (HTTP/1.1): almacenamiento en caché. Grupo de trabajo de ingeniería de Internet (IETF). doi : 10.17487/RFC7234 . RFC 7234. Norma propuesta, sección 5.5. Queda obsoleta por la RFC 9111. Deja obsoleta la RFC 2616.

[58] "Advertencia: HTTP | MDN". developer.mozilla.org . Consultado el 15 de agosto de 2021 . Este artículo incorpora texto disponible bajo la licencia CC BY-SA 2.5.

[59] "Advertencia". Almacenamiento en caché HTTP. Junio de 2022. Sección 5.5. doi : 10.17487/RFC9111 . RFC 9111.