Detalles del código de estado HTTP

Un código de estado HTTP es un código de tres dígitos que indica el estado de la respuesta del Protocolo de transferencia de hipertexto de un servidor web. Está definido por la especificación RFC 2616 y ampliado por RFC 2518, RFC 2817, RFC 2295, RFC 2774 y RFC 4918. El primer dígito de todos los códigos de estado representa uno de los cinco estados del eco. Las frases informativas que se muestran son típicas, pero se puede proporcionar cualquier frase alternativa legible. A menos que se indique lo contrario, los códigos de estado son parte del estándar HTTP/1.1 (RFC 7231).

El registro oficial de códigos de estado HTTP lo mantiene la Autoridad de Números Interasignados.

Microsoft Inter Information Services a veces utiliza subcódigos decimales adicionales para proporcionar información más específica, pero estos subcódigos solo aparecen en respuestas a cargas útiles y documentos y no reemplazan el código de estado HTTP real. Introducción básica Nombre chino: Código de estado HTTP Nombre extranjero: Código de estado HTTP Definición de especificación: RFC 2616 Fin del mensaje: 1 información de encabezado, 2 información de encabezado, 3 información de encabezado, 100 Continuar, 101 Protocolos de conmutación, 102 Procesamiento, Éxito, 200 Aceptar, 201 Creado, 202 Aprobado, 203 Información no autorizada, 204 Sin contenido, 205 Restablecer contenido, 206 Contenido parcial, 207 Estado múltiple, Redirección, 300 Selección múltiple, 301 Movimiento permanente, 302 Movimiento temporal, 303 Ver otros, 304 Sin modificar, 305 Usar proxy, 306 Cambiar proxy, 307 Redirección temporal, Solicitud incorrecta, 401 Solicitud no autorizada, 400 Solicitud incorrecta, 401 No autorizado, 402 Pago requerido, 403 Prohibido, 404 No encontrado, 405 Método no permitido, 406 No es posible Aceptar, 407 Se requiere autenticación de proxy, 408 Tiempo de espera de solicitud, 409 Conflicto, 410 Desaparece, 411 Longitud requerida, 412 Condición previa fallida, 413 Entidad de solicitud demasiado grande, 414 URI de solicitud demasiado larga, 415 Tipo de medio no admitido, 416 Rango solicitado no satisfactorio, 417 Expectativa fallida, 418 Soy una tetera, 421 Demasiadas conexiones, 422 Entidad no procesable, 423 Bloqueada, 424 Dependencia fallida, 425 Colección desordenada, 426 Actualización requerida, 449 Reintentar con, 451 No disponible por razones legales, Error del servidor, 500 Error interno del servidor, 501 No ejecutado, 502 Fallo de puerta de enlace, 503 Servicio no disponible, 504 Tiempo de espera de puerta de enlace, 505 Versión HTTP no compatible, 506 Variante también negociada, 507 Espacio de almacenamiento insuficiente, 509 Límite de ancho de banda excedido, 510 No expandido, 600 No se puede analizar el encabezado de respuesta, código de estado del mensaje indica que la solicitud ha sido aceptada y requiere procesamiento adicional.

Este tipo de respuesta es una respuesta provisional que contiene solo una línea de estado y alguna información de encabezado de respuesta opcional, y termina con una línea en blanco. Dado que los códigos de estado 1xx no están definidos en el protocolo HTTP/1.0, los servidores tienen prohibido transmitir recibos 1xx a dichos clientes, excepto bajo ciertas condiciones experimentales. 100 Continuar El cliente debe continuar transmitiendo la solicitud. Este eco temporal se utiliza para notificar al cliente que el servidor ha recibido parte de su solicitud y aún no la ha rechazado. El cliente debe continuar transmitiendo el resto de la solicitud o ignorar este eco si la solicitud se ha completado. Una vez completada la solicitud, el servidor debe enviar un eco final al cliente. 101 Cambio de protocolo El servidor ha comprendido la solicitud del cliente y le notificará a través del encabezado Actualización para completar la solicitud utilizando un protocolo diferente. Después de transmitir la última línea vacía de este eco, el servidor cambia al protocolo definido en el encabezado Actualización. Esto sólo se hará si resulta más ventajoso cambiar a un nuevo protocolo. Por ejemplo, cambiar a una nueva versión de HTTP es más beneficioso que una versión anterior, o cambiar a un protocolo sincrónico en tiempo real para entregar recursos que aprovechen dichas capacidades. 102 Código de estado de procesamiento extendido por WebDAV (RFC 2518) para indicar que el procesamiento continuará. Éxito Este código de estado indica que el servidor recibió, entendió y aceptó exitosamente la solicitud. 200 OK La solicitud se realizó correctamente y el encabezado de eco o el cuerpo de datos requerido por la solicitud se devolverá junto con este eco. La presencia de este código de estado indica un estado normal. 201 Creado La solicitud se cumplió y se creó un nuevo recurso basado en la solicitud y su URI se devolvió con el encabezado Ubicación. Si los recursos necesarios no se pueden crear a tiempo, se debe devolver "202 Aepted". 202 Aepted El servidor aceptó la solicitud pero aún no la procesó. Así como una solicitud puede ser denegada, en última instancia puede o no ejecutarse. En el caso de operaciones asincrónicas, nada más conveniente que transmitir este código de estado. El propósito de que el eco devuelva un código de estado 202 es permitir que el servidor acepte solicitudes de otros procesos (como una operación por lotes que solo se realiza una vez al día) sin tener que mantener al cliente conectado al servidor hasta que la operación por lotes haya finalizado por completo. terminado. Un eco que acepta una solicitud de procesamiento y devuelve un código de estado 202 debe contener alguna información en la entidad devuelta que indique el estado actual del proceso, así como un puntero a un monitor de estado del proceso o predicción de estado para que el usuario pueda estimar si el la operación ha finalizado. 203 Información no autorizada El servidor procesó con éxito la solicitud, pero la información del encabezado de la entidad devuelta no es un conjunto válido y determinado en el servidor original, sino una copia de un local o de un tercero. La información actual puede ser un subconjunto o un superconjunto de la versión original. Por ejemplo, contener metadatos para un recurso podría hacer que el servidor de origen conozca un superconjunto de la metainformación. No es necesario utilizar este código de estado y solo es apropiado si el eco devuelve 200 OK. 204 Sin contenido El servidor procesó exitosamente la solicitud pero no necesita devolver ningún contenido de entidad. En cambio, espera devolver metainformación actualizada. La respuesta puede devolver metainformación nueva o actualizada en forma de encabezados de entidad. Si dichos encabezados están presentes, deben corresponder a las variables solicitadas. Si el cliente es un navegador, entonces el navegador del usuario DEBE conservar la página desde la que se envió la solicitud sin realizar ningún cambio en la vista del documento, aunque según la especificación, se debe aplicar metainformación nueva o actualizada al documento en el navegador del usuario. vista activa. Dado que un eco 204 tiene prohibido contener cualquier cuerpo de mensaje, siempre termina con la primera línea vacía después del encabezado del mensaje. 205 Restablecer el servidor de contenido maneja exitosamente la solicitud pero no devuelve ningún contenido. Pero a diferencia de un eco 204, un eco que devuelve este código de estado requiere que el solicitante restablezca la vista del documento. Este eco se utiliza principalmente para restablecer el formulario inmediatamente después de aceptar la entrada del usuario, de modo que el usuario pueda iniciar fácilmente una nueva entrada. Al igual que el eco 204, este eco también tiene prohibido contener cualquier cuerpo de mensaje y termina con la primera línea en blanco después del encabezado del mensaje.

206 Algunas solicitudes GET fueron procesadas exitosamente por el servidor de contenido parcial. Las herramientas de descarga HTTP (como FlashGet o Thunder) utilizan este eco para realizar descargas intermitentes o para dividir archivos grandes en varios archivos para descargarlos simultáneamente. La solicitud debe incluir un encabezado Range para indicar el rango de contenido que desea el cliente y puede incluir If-Range como condición de solicitud. La respuesta debe contener los siguientes campos de encabezado: Content-Range, que indica el rango de contenido que se devolverá en esta respuesta en el caso de una descarga multiparte con tipo de contenido multipart/byteranges, en cada multipart se utiliza un campo Content-Range; para indicar el rango de contenido del segmento. Si Content-Length se incluye en el eco, su valor debe coincidir con el número real de bytes en el rango de contenido devuelto. Fecha ETag y/o Ubicación del contenido si la misma solicitud debería haber devuelto una respuesta 200. Expires, Cache-Control y/o Vary, si su valor puede ser diferente del valor correspondiente a otras respuestas anteriores a la misma variable. Si la solicitud usa una validación de caché fuerte de If-Range, este eco no debe contener otros encabezados de entidad; si la solicitud usa una validación de caché débil de If-Range, este eco no debe contener otros encabezados de entidad, esto evita entidades almacenadas en caché. El contenido es inconsistente con la entidad actualizada; encabezados. De lo contrario, el eco debería contener todos los campos de encabezado de entidad que se habrían devuelto en un eco 200. Si el encabezado ETag o Last-Modified no coincide exactamente, la caché del cliente debe deshabilitar la combinación del contenido devuelto por el eco 206 con cualquier contenido previamente almacenado en caché. 207 Estado múltiple Un código de estado extendido por WebDAV (RFC 2518) que indica que el cuerpo del mensaje posterior será un mensaje XML y puede contener una serie de códigos de eco separados, dependiendo del número de subsolicitudes anteriores. Redirigir Este código de estado indica que el cliente debe realizar más acciones para completar la solicitud. Normalmente, estos códigos de estado se utilizan para redirecciones y la dirección de solicitudes posteriores (el destino de la redirección) se anota en el campo de ubicación del eco actual. El navegador del usuario enviará automáticamente las solicitudes posteriores requeridas sin la intervención del usuario solo si el método utilizado para la solicitud posterior es GET o HEAD. Los clientes deben monitorear automáticamente las redirecciones de bucle infinito (como A-gt;A o A-gt;B-gt;C-gt;A), ya que esto puede hacer que el servidor y el cliente consuman grandes cantidades de recursos innecesarios. La especificación HTTP versión 1.0 recomienda que los navegadores accedan automáticamente a los redireccionamientos no más de cinco veces. Más de 300 opciones El recurso solicitado tiene una variedad de retornos alternativos, cada uno con su propia dirección específica e información de negociación basada en el navegador. Los usuarios o navegadores pueden elegir su dirección preferida para la redirección. A menos que sea una solicitud HEAD, el eco debe contener una entidad, una lista de características de recursos y direcciones entre las cuales el usuario o el navegador puede elegir la dirección de redireccionamiento más adecuada. El formato de esta entidad está determinado por el formato definido por Content-Type. El navegador puede realizar automáticamente la elección más adecuada según el formato del eco y las propias capacidades del navegador. Por supuesto, la especificación RFC 2616 no especifica cómo se realiza esta selección automática. Si el servidor ya tiene un eco preferido, el URI para ese eco debe especificarse en Ubicación; el navegador puede usar este valor de Ubicación como dirección para redireccionamientos automáticos. Además, a menos que se indique lo contrario, este eco también se puede almacenar en caché. 301 Movido permanentemente El recurso solicitado se ha movido permanentemente a una nueva ubicación y cualquier referencia futura al recurso debe utilizar uno de los URI devueltos por este eco. Si es posible, los clientes con capacidades de edición de enlaces deben cambiar automáticamente la dirección solicitada a la dirección devuelta por el servidor.

A menos que se indique lo contrario, este eco también se puede almacenar en caché. El nuevo URI permanente debe devolverse en el campo Ubicación de echo. A menos que sea una solicitud HEAD, la entidad de eco debe contener un hipervínculo al nuevo URI y una breve descripción. Si no se trata de una solicitud GET o HEAD, el navegador no puede redirigir automáticamente sin la confirmación del usuario, ya que las condiciones de la solicitud pueden cambiar en consecuencia. Nota: Para algunos navegadores que utilizan el protocolo HTTP/1.0, cuando envían una solicitud POST con una respuesta 301, la siguiente solicitud de redireccionamiento será un GET. 302 Mover temporalmente solicita temporalmente un recurso de un URI diferente. Debido a que la redirección es temporal, el cliente debe continuar enviando solicitudes futuras a la dirección original. Este eco se puede almacenar en caché solo si se especifica en Cache-Control o Expires mencionado anteriormente. Si no se trata de una solicitud GET o HEAD, el navegador NO DEBE redirigir automáticamente a menos que lo confirme el usuario, ya que las condiciones de la solicitud pueden cambiar como resultado. Nota: Aunque las especificaciones RFC 1945 y RFC 2068 no permiten que el cliente cambie el método de la solicitud al redirigir, muchos navegadores existentes tratarán el eco 302 como eco 303 y utilizarán GET para acceder al URI especificado en la Ubicación, ignorando el original. Método de solicitud. Se agregaron los códigos de estado 303 y 307 para aclarar qué espera el servidor del cliente. 303 Ver otros La respuesta a la solicitud actual se puede encontrar en otra URL y el cliente debe usar GET para acceder a ese recurso. Este método se utiliza principalmente para redirigir la salida de una solicitud POST activada por script a un nuevo recurso. Este nuevo URI no es una referencia de reemplazo del recurso original. Además, se prohíbe el almacenamiento en caché del eco 303. Por supuesto, la segunda solicitud (redireccionamiento) se puede almacenar en caché. Nota: Muchos navegadores anteriores a la versión HTTP 1.1 no comprenden correctamente el estado 303. Si necesita considerar interactuar con estos navegadores, el código de estado 302 puede resolver el problema, porque la mayoría de los navegadores manejan 302 ecos exactamente de la misma manera que la especificación anterior requiere que los clientes manejen 303 ecos. 304 No modificado El servidor debe devolver este código de estado si se permite una solicitud GET condicional transmitida por el cliente y el contenido del documento no ha cambiado (desde el último acceso o según las condiciones de la solicitud). Los ecos 304 tienen prohibido contener cuerpos de mensajes y, por lo tanto, siempre terminan con la primera línea vacía después del encabezado del mensaje. El eco debe contener la siguiente información de encabezado: Fecha, a menos que el servidor no tenga reloj. Si los servidores sin reloj cumplen con estas reglas, entonces los servidores proxy y los clientes pueden agregar campos de fecha a los encabezados de eco entrantes (como se especifica en RFC 2068) y el mecanismo de almacenamiento en caché funcionará correctamente. ETag y/o Content-Location si la misma solicitud debería haber devuelto una respuesta 200. Expires, Cache-Control y/o Vary, si sus valores pueden diferir de otras respuestas anteriores con la misma variable. Si esta solicitud de eco utiliza un almacenamiento en caché fuerte, este eco no debe contener otros encabezados de entidad; de lo contrario (por ejemplo, una solicitud GET condicional usa un almacenamiento en caché débil), este eco NO DEBE contener otros encabezados de entidad, esto evita que el contenido de la entidad en caché sea inconsistente con la entidad actualizada; Los encabezados son inconsistentes. Si un eco 304 indica que la entidad no está actualmente almacenada en caché, el sistema de almacenamiento en caché DEBE ignorar el eco y repetir la solicitud sin limitar. Si se recibe una solicitud de eco 304 para actualizar una entrada de caché, el sistema de caché debe actualizar la entrada completa para reflejar los valores de todos los campos actualizados en el eco.

305 Uso del proxy Se debe acceder al recurso solicitado a través del proxy especificado y el campo Ubicación proporcionará información sobre el URI donde se encuentra el proxy especificado. Sólo el servidor de origen puede establecer un eco 305. Nota: RFC 2068 no establece explícitamente que el propósito de un eco 305 sea redirigir una única solicitud y solo puede establecerlo el servidor de origen. Ignorar estas restricciones puede tener graves consecuencias para la seguridad. Agente de intercambio 306 El código de estado 306 ya no se utiliza en la última versión de la especificación. 307 Redirección temporal El recurso solicitado respondió temporalmente a la solicitud desde un URI diferente. El nuevo URI temporal debe devolverse en el campo Ubicación de la respuesta. A menos que sea una solicitud HEAD, la entidad devuelta debe contener un hipervínculo al nuevo URI y una breve descripción. Debido a que algunos navegadores no reconocen el eco 307, es necesario agregar la información anterior para que los usuarios puedan comprender y solicitar acceso al nuevo URI. Si no se trata de una solicitud GET o HEAD, el navegador desactiva la redirección automática a menos que el usuario lo confirme, ya que las condiciones de la solicitud pueden cambiar como resultado. Error de solicitud Este código de estado indica que puede haber ocurrido un error del cliente, lo que impide que el servidor procese la solicitud. A menos que el eco sea una solicitud HEAD, el servidor debe devolver una entidad que explique la condición de error actual y si es temporal o permanente. Estos códigos de estado se aplican a cualquier método de solicitud. Los navegadores DEBEN mostrar al usuario el contenido de cualquier entidad contenida en dichos ecos de error. Si el cliente está transmitiendo datos cuando ocurre un error, las implementaciones del servidor que utilizan TCP deben asegurarse cuidadosamente de que el cliente haya recibido un paquete que contenga la información del error antes de cerrar la conexión entre el cliente y el servidor. Si el cliente continúa enviando datos al servidor después de recibir el mensaje de error, la pila de protocolo TCP del servidor enviará un paquete de reinicio al cliente para borrar todos los buffers de entrada que aún no reconoce el cliente, de modo que la aplicación en el servidor Estos datos no será leído ni interferirá con este último. 400 Solicitud incorrecta 1. Error semántico, el servidor no puede comprender la solicitud actual. El cliente no debe volver a enviar la solicitud a menos que se modifique la solicitud. 2. Los parámetros de la solicitud son incorrectos. 401 No autorizado La solicitud actual requiere autenticación de usuario. La respuesta debe incluir un encabezado -Authenticate apropiado para el recurso solicitado, solicitando información del usuario. El cliente puede enviar repetidamente la solicitud con el encabezado de autorización apropiado. Si la solicitud actual ya contiene certificados autorizados, un eco 401 verifica en nombre del servidor que estos certificados han sido rechazados. Si el eco 401 contiene la misma consulta de validación que el eco anterior y el navegador ya ha intentado la validación al menos una vez, el navegador debe proporcionar al usuario la información de la entidad contenida en el eco, ya que esta información de la entidad puede contener información de diagnóstico relevante. Consulte RFC 2617. 402 Pago solicitado Este código de estado está reservado para posibles requisitos futuros. 403 Prohibido El servidor entendió la solicitud pero se negó a ejecutarla. A diferencia del eco 401, la autenticación no proporciona ninguna ayuda y la solicitud no debe volver a enviarse. Si esta no es una solicitud HEAD y el servidor quiere poder explicar por qué no puede realizar la solicitud, entonces el motivo del rechazo debe indicarse en la entidad. Por supuesto, si el servidor no quiere que el cliente obtenga ninguna información, también puede devolver un eco 404. 404 No encontrado La solicitud falló y el recurso solicitado no se encontró en el servidor. No hay información que indique a los usuarios si esta condición es temporal o permanente. Si el servidor es consciente de esta situación, debe utilizar un código de estado 410 para informar al usuario que debido a algún mecanismo de configuración interna, el recurso antiguo no está disponible permanentemente y no hay redireccionamientos disponibles. 404 se usa ampliamente cuando el servidor no quiere revelar el motivo por el cual se rechazó la solicitud o no hay otra respuesta adecuada. La causa más probable de este error es que la página no esté disponible en el servidor. 405 Método no permitido El método de solicitud especificado en la línea de solicitud no se puede utilizar para solicitar el recurso correspondiente.

La respuesta debe devolver un encabezado Permitir que indique la lista de métodos de solicitud aceptables para el recurso actual. Debido a que los métodos PUT y DELETE escriben en recursos del servidor, la mayoría de los servidores web no admiten ni permiten estos métodos de solicitud de forma predeterminada, y dichas solicitudes devolverán un error 405. 406 No apto Las características de contenido del recurso solicitado no cumplen con las condiciones en el encabezado de la solicitud, por lo que no se puede generar la entidad de eco. A menos que sea una solicitud HEAD, la respuesta debe devolver una entidad que contenga una lista de características y direcciones de entidades, entre las cuales el usuario o navegador puede elegir la entidad más adecuada. El formato de la entidad está determinado por el tipo de medio definido en el encabezado Content-Type. El navegador puede tomar la mejor decisión según el formato y sus capacidades. Sin embargo, esta especificación no define criterios para la selección automática. 407 Se requiere autenticación de proxy es similar al eco 401, pero el cliente debe autenticarse en el servidor proxy. El servidor proxy debe devolver Proxy-Authenticate para la autenticación. El cliente puede devolver el encabezado Proxy-Authorization para autenticación. Consulte RFC 2617. 408 Tiempo de espera de solicitud Se agotó el tiempo de espera de la solicitud. El cliente no completó la entrega de la solicitud dentro del tiempo que el servidor estaba preparado para esperar. El cliente puede volver a enviar la solicitud en cualquier momento sin realizar ningún cambio. 409 Conflicto La solicitud no se puede completar debido a un conflicto con el estado actual del recurso solicitado. Este código solo se permite si el usuario cree que puede resolver el conflicto y volver a enviar una nueva solicitud. El eco debe contener suficiente información para que el usuario descubra el origen del conflicto. Los conflictos suelen ocurrir durante el procesamiento de solicitudes PUT. Por ejemplo, en un entorno de verificación de versiones, si la información de versión adjunta a una confirmación PUT que solicita cambios a un recurso específico entra en conflicto con una solicitud anterior (de terceros), el servidor devolverá un error 409 para informar al usuario que la solicitud no se puede completar. En este punto, la entidad de eco puede comparar las diferencias entre las dos versiones en conflicto para que el usuario pueda volver a enviar la nueva versión después de la fusión. 410 Desaparecido El recurso solicitado ya no está disponible en el servidor y no tiene ninguna dirección de reenvío conocida. Esta condición debe considerarse permanente. Si es posible, los clientes con capacidades de edición de enlaces deben eliminar todas las referencias a esta dirección con el permiso del usuario. Si el servidor no sabe o no puede determinar si la condición es permanente, debe usar el código de estado 404. A menos que se indique lo contrario, este eco se puede almacenar en caché. El objetivo principal de 410 echo es ayudar a los administradores del sitio web a mantener el sitio web, notificar a los usuarios que el recurso ya no está disponible y el propietario del servidor también desea eliminar todas las conexiones remotas al recurso. Este tipo de evento es común en los servicios de valor agregado por tiempo limitado. De manera similar, el eco 410 también se utiliza para notificar al cliente que los recursos personales en el sitio del servidor actual ya no están disponibles. Por supuesto, depende totalmente del propietario del servidor si todos los recursos que no están disponibles permanentemente deben marcarse como "410 desaparecido" y durante cuánto tiempo deben conservarse. 411 Longitud requerida El servidor se niega a aceptar solicitudes con información de encabezado de longitud de contenido indefinida. El cliente puede volver a enviar la solicitud después de agregar un encabezado Content-Length válido e indicar la longitud del cuerpo de la solicitud. 412 Error de condición previa El servidor no cumplió con una o más condiciones previas dadas en los campos del encabezado de la solicitud mientras las validaba. Este código de estado permite al cliente establecer condiciones previas en la metainformación de la solicitud (datos del campo del encabezado de la solicitud) al obtener el recurso, evitando así que el método de solicitud se aplique a un recurso distinto al que requiere. 413 Entidad de solicitud demasiado grande El servidor se niega a procesar la solicitud actual porque envió más datos de entidad de los que el servidor está dispuesto o es capaz de manejar. En este caso, el servidor puede cerrar la conexión, impidiendo que el cliente continúe transmitiendo solicitudes.

Si la situación es temporal, el servidor debe devolver un encabezado de eco posterior al reintento para informar al cliente cuándo puede volver a intentarlo. 414 Request-URI Too Long El URI solicitado es más largo de lo que el servidor puede interpretar, por lo que el servidor se niega a atender la solicitud. Esta situación es relativamente rara. Las situaciones comunes incluyen el formulario que debe enviarse utilizando el método POST en lugar del método GET, lo que da como resultado una cadena de consulta demasiado larga. Redireccionamiento de URI "agujeros negros", como el uso del URI antiguo como parte del nuevo URI para cada redireccionamiento, lo que da como resultado un URI demasiado largo después de múltiples redireccionamientos. El cliente intenta aprovechar las vulnerabilidades de seguridad de algunos servidores para atacar el servidor. Este tipo de servidor utiliza un búfer de longitud fija para leer o procesar el URI solicitado. Cuando los parámetros después de GET exceden un cierto valor, puede causar un desbordamiento del búfer, lo que lleva a la ejecución de código arbitrario [1]. Los servidores que no tienen dicha vulnerabilidad deberían devolver un código de estado 414. 415 Tipo de medio no admitido Para el método solicitado actualmente y el recurso solicitado, la entidad enviada en la solicitud no está en un formato admitido por el servidor y la solicitud se rechaza. 416 Rango de solicitud insatisfecho Si la solicitud contiene un encabezado de solicitud de rango y cualquier rango de datos especificado en el rango no coincide con el rango disponible del recurso actual y el encabezado de solicitud If-Range no está definido en la solicitud, el servidor debe devolver un código de estado 416. Si Range utiliza un rango de tuplas, esto significa que la primera posición de tupla de todos los rangos de datos especificados en la solicitud excede la longitud del recurso actual. El servidor también debe incluir un encabezado de entidad Content-Range que indique la longitud del recurso actual y el código de estado 416. Este eco también desactiva el uso de rangos multiparte/bytes como tipo de contenido. 417 Expect falló. El contenido esperado especificado en el encabezado de la solicitud Expect no puede ser realizado por el servidor, o el servidor es un servidor proxy, y hay evidencia clara de que el contenido de Expect no se puede realizar en el siguiente nodo de la ruta actual. 418 Soy una tetera 421 Demasiadas conexiones Hay demasiadas conexiones entre la dirección IP del cliente actual y el servidor, superando el máximo permitido por el servidor. Normalmente, la dirección IP en este caso es la dirección del cliente vista desde el servidor (como la puerta de enlace del usuario o la dirección del servidor proxy). En este caso, el cálculo del número de conexiones puede implicar a más de un usuario final. 422 Entidad no controlada La solicitud estaba bien formada pero no se pudo devolver porque contenía un error semántico. (RFC 4918 WebDAV) 423 Bloqueado El recurso actual está bloqueado. (RFC 4918 WebDAV) 424 Fallo de dependencia La solicitud actual falló debido a un error en una solicitud anterior (como PROPPATCH). (RFC 4918 WebDAV) 425 Colecciones desordenadas Definidas en el borrador de Colecciones avanzadas de WebDav, pero no presentes en el protocolo de Colecciones ordenadas de WebDAV (RFC 3658). 426 Actualización requerida El cliente debe cambiar a TLS/1.0. (RFC 2817) 449 Reintentar con Extendido por Microsoft para indicar que se debe volver a intentar una solicitud después de tomar la acción adecuada. 451 No disponible por motivos legales La solicitud no está disponible por motivos legales. (RFC 7725) Error del servidor (prefijo 5, 6) Este código de estado indica que se produjo un error o excepción mientras el servidor estaba procesando la solicitud, o que el servidor se dio cuenta de que el procesamiento de la solicitud no se podía completar con su hardware y software actuales. recursos. A menos que se trate de una solicitud HEAD, el servidor DEBE incluir una entidad que explique el estado del error actual y si el estado es temporal o permanente. El navegador debe mostrar al usuario cualquier entidad contenida en el eco actual.

Estos códigos de estado se aplican a cualquier método de eco. 500 Error interno del servidor El servidor encontró una condición inesperada y no pudo completar el procesamiento de la solicitud. Generalmente, este problema ocurre cuando hay un error en el código fuente del lado del servidor. 501 No ejecutado El servidor no admite la funcionalidad requerida por la solicitud actual. Esta situación ocurre cuando el servidor no reconoce el método solicitado y no puede admitir su solicitud de ningún recurso. 502 Puerta de enlace incorrecta El servidor que actúa como puerta de enlace o proxy recibió un eco no válido del servidor ascendente al intentar realizar una solicitud. 503 Servicio no disponible El servidor actualmente no puede procesar la solicitud debido a un mantenimiento temporal o sobrecarga del servidor. Esta condición es temporal y se recuperará después de un tiempo. Si se esperan retrasos, incluya un encabezado posterior al reintento en la respuesta para tener en cuenta los retrasos. Si no se proporciona información posterior al reintento, el cliente debe manejarlo de la misma manera que un eco 500. Nota: La presencia del código de estado 503 no significa que el servidor deba usarlo cuando está sobrecargado. Algunos servidores simplemente quieren rechazar la conexión del cliente. 504 Tiempo de espera de puerta de enlace Un servidor que actúa como puerta de enlace o proxy no pudo recibir un eco a tiempo de un servidor ascendente (el servidor identificado por el URI, como HTTP, FTP, LDAP) o un servidor secundario (como DNS) al intentar realizar una solicitud. 505 Versión HTTP no compatible El servidor no admite o se niega a admitir la versión HTTP utilizada en la solicitud. Esto significa que el servidor no puede o no utilizará la misma versión que el cliente. La respuesta debe contener una entidad que indique por qué no se admite la versión y qué protocolos admite el servidor. La variante 506 también negocia se extiende por el protocolo de negociación de contenido transparente (RFC 2295) y representa un error de configuración interno del servidor: el recurso de variante de negociación solicitado está configurado para usarse en la negociación de contenido transparente y, por lo tanto, no es el foco apropiado durante el proceso de negociación. El servidor no puede almacenar el contenido necesario para satisfacer la solicitud. WebDAV (RFC 4918) 509 Límite de ancho de banda excedido El servidor ha alcanzado su límite de ancho de banda. Este no es un código de estado oficial, pero todavía se usa ampliamente. 510 No ampliado No se cumplió la política requerida para obtener el recurso. (RFC 2774) 600 Encabezados de respuesta no analizables La fuente no devolvió encabezados de respuesta, solo contenido de la entidad.