Herramientas en línea
Códigos de Estado Http Código de estado Significado
100 El cliente debe continuar enviando peticiones. Esta respuesta temporal se utiliza para informar al cliente de que parte de su solicitud ha sido recibida por el servidor y no ha sido rechazada. El cliente debe continuar enviando el resto de la petición, o ignorar esta respuesta si la petición está completa. El servidor debe enviar una respuesta final al cliente cuando la petición esté completa.
101 El servidor ha entendido la petición del cliente y le notificará a través de la cabecera Upgrade que se ha utilizado un protocolo diferente para completar la petición. Después de enviar la última línea en blanco de la respuesta, el servidor cambiará a los protocolos definidos en la cabecera Upgrade. Esto sólo debe hacerse si es más ventajoso cambiar al nuevo protocolo. Por ejemplo, cambiar a una nueva versión de HTTP puede ser más ventajoso que una versión anterior, o cambiar a un protocolo síncrono en tiempo real para entregar recursos que aprovechen tales características.
102 Los códigos de estado, ampliados por WebDAV (RFC 2518), indican que el procesamiento continuará.
200 La solicitud se ha realizado correctamente, y las cabeceras de respuesta o el cuerpo de datos deseados por la solicitud se devolverán con la respuesta.
201 La solicitud se ha cumplido y se ha creado un nuevo recurso en respuesta a la solicitud, y su URI se ha devuelto con la cabecera Location. Si el recurso solicitado no puede crearse a tiempo, se devolverá lo siguiente'202 Accepted'。
202 El servidor ha aceptado la solicitud, pero aún no la ha procesado. Al igual que puede ser rechazada, la petición puede o no ser ejecutada finalmente. En el caso de operaciones asíncronas, no hay nada más conveniente que enviar este código de estado. El propósito de devolver una respuesta 202 es permitir al servidor aceptar peticiones de otros procesos (como una operación por lotes que se ejecuta sólo una vez al día) sin que el cliente tenga que mantener una conexión con el servidor hasta que la operación por lotes se haya completado. Una respuesta que acepte una solicitud de procesamiento y devuelva un código de estado 202 debe incluir en la entidad devuelta alguna información que indique el estado actual del proceso, así como un puntero a un monitor de estado de procesamiento o predicción de estado, para que el usuario pueda estimar si la operación ha finalizado o no.
203 El servidor ha procesado con éxito la solicitud, pero la metainformación de la cabecera de la entidad devuelta no es un conjunto definitivo válido en el servidor original, sino una copia procedente de un servidor local o de terceros. La información actual puede ser un subconjunto o un superconjunto de la original. Por ejemplo, los metadatos que contienen recursos pueden hacer que el servidor de origen conozca la superinformación. El uso de este código de estado no es obligatorio y sólo es apropiado si la respuesta hubiera devuelto 200 OK sin él.
204 El servidor procesó la solicitud correctamente, pero no necesita devolver ningún contenido físico y desea devolver metainformación actualizada. La respuesta puede devolver meta-información nueva o actualizada en forma de cabeceras de entidad. Si estas cabeceras existen, deben corresponder a las variables solicitadas. Si el cliente es un navegador, el navegador del usuario DEBERÍA retener la página en la que se envió la petición sin ningún cambio en la vista del documento, aunque la meta-información nueva o actualizada DEBERÍA, de acuerdo con la especificación, aplicarse al documento en la vista activa del navegador del usuario. Dado que la respuesta 204 no puede contener ningún cuerpo de mensaje, siempre termina con la primera línea en blanco después de la cabecera del mensaje.
205 El servidor gestiona correctamente la solicitud y no devuelve nada. Sin embargo, a diferencia de la respuesta 204, la respuesta que devuelve este código de estado pide al solicitante que restablezca la vista del documento. Esta respuesta se utiliza principalmente para restablecer el formulario inmediatamente después de aceptar la entrada del usuario, de forma que éste pueda iniciar fácilmente otra entrada. Al igual que la respuesta 204, esta respuesta no puede contener ningún cuerpo de mensaje y termina con la primera línea en blanco después de la cabecera del mensaje.
206 El servidor ha procesado con éxito parte de la solicitud GET. Las herramientas de descarga HTTP como FlashGet o Thunderbolt utilizan este tipo de respuesta para realizar descargas intermitentes o para dividir un archivo grande en varias descargas al mismo tiempo. La solicitud debe contener una cabecera Range para indicar el rango de contenido que el cliente desea recibir, y puede contener un If-Range como condición de la solicitud. La respuesta debe contener los siguientes campos de encabezado: Content-Range para indicar el alcance del contenido devuelto en esta respuesta o, en el caso de descargas multiparte con un Content-Type de multipart/byteranges, un campo Content-Range en cada segmento multiparte para indicar el alcance del contenido en ese segmento. Si la respuesta contiene un Content-Length, su valor debe coincidir con el número real de bytes en el rango de contenido que devuelve. Expires, Cache-Control, y/o Vary, si sus valores pueden ser diferentes de los valores de otras respuestas anteriores con las mismas variables. Esta respuesta no debería contener otras cabeceras de entidad si la petición utiliza validación de caché If-Range fuerte, y no debería contener otras cabeceras de entidad si la petición utiliza validación de caché If-Range débil; esto evita inconsistencias entre el contenido de entidad en caché y la información de cabecera de entidad actualizada. De otro modo, esta respuesta DEBERÍA contener todos los campos de cabecera de entidad que deberían haber sido devueltos en la respuesta 200. Si las cabeceras ETag o Last-Modified no coinciden exactamente, la caché del cliente no debería permitir la combinación del contenido devuelto en la respuesta 206 con cualquier contenido previamente almacenado en caché. Cualquier caché que no soporte las cabeceras Range y Content-Range tiene prohibido almacenar en caché el contenido devuelto por la respuesta 206.
207 Códigos de estado ampliados por WebDAV(RFC 2518) El código de estado, ampliado por WebDAV, significa que el cuerpo del mensaje posterior será un mensaje XML y puede contener una serie de códigos de respuesta independientes, en función del número de subpeticiones anteriores.
300 El recurso solicitado tiene una serie de respuestas alternativas, cada una con su propia dirección específica e información de negociación basada en el navegador. Corresponde al usuario o al navegador elegir una dirección preferida para la redirección. A menos que se trate de una petición HEAD, la respuesta debe incluir una entidad que sea una lista de características y direcciones del recurso a partir de la cual el usuario o el navegador puedan seleccionar la dirección de redirección más apropiada. El formato de esta entidad viene determinado por el formato de la definición Content-Type. El navegador puede hacer automáticamente la selección más apropiada basándose en el formato de la respuesta y en las propias capacidades del navegador. Por supuesto, la especificación RFC 2616 no especifica cómo debe hacerse esta selección automática. Si el propio servidor ya tiene una opción de retorno preferida, el URI del retorno debe especificarse en la Ubicación; los navegadores pueden usar este valor de Ubicación como la dirección para la redirección automática. Además, la respuesta es almacenable en caché a menos que se especifique lo contrario.
301 El recurso solicitado se ha movido permanentemente a la nueva ubicación, y cualquier referencia futura al mismo deberá utilizar uno de los varios URI devueltos en esta respuesta. Si es posible, los clientes con capacidades de edición de enlaces deberían cambiar automáticamente la dirección solicitada por la devuelta por el servidor. Esta respuesta también es almacenable en caché a menos que se especifique lo contrario. El nuevo URI permanente debe ser devuelto en el campo Location de la respuesta. A menos que se trate de una solicitud HEAD, la entidad de respuesta debe contener un hipervínculo al nuevo URI y una breve descripción. Si no se trata de una petición GET o HEAD, se prohíbe al navegador redirigir automáticamente a menos que el usuario lo confirme, ya que los términos de la petición pueden cambiar como resultado. Nota: Para algunos navegadores que utilizan el protocolo HTTP/1.0, cuando envían una petición POST y obtienen una respuesta 301, la siguiente petición de redirección será GET.
302 El recurso solicitado responde ahora temporalmente a la petición desde un URI diferente. Dado que esta redirección es temporal, el cliente debe seguir enviando futuras peticiones a la dirección original. La respuesta es almacenable en caché sólo si se especifica en Cache-Control o Expires. El nuevo URI temporal debe devolverse en el campo Location de la respuesta. A menos que se trate de una solicitud HEAD, la entidad de respuesta debe contener un hipervínculo al nuevo URI y una breve descripción. Si no se trata de una petición GET o HEAD, se prohíbe al navegador redirigir automáticamente a menos que el usuario lo confirme, ya que los términos de la petición pueden cambiar como resultado. Nota: Aunque las especificaciones RFC 1945 y RFC 2068 no permiten al cliente cambiar el método de la petición durante la redirección, muchos navegadores existentes tratan la respuesta 302 como una respuesta 303 y utilizan GET para acceder al URI especificado en la Localización, ignorando el método de la petición original. Los códigos de estado 303 y 307 se han añadido para aclarar qué respuesta espera el servidor del cliente.
303 La respuesta a la petición actual puede encontrarse en otro URI, y el cliente debe acceder a ese recurso utilizando GET. Este método existe principalmente para permitir que la salida de la solicitud POST activada por script sea redirigida a un nuevo recurso. Este nuevo URI no es una referencia de reemplazo al recurso original. Además, la respuesta 303 no puede almacenarse en caché. Por supuesto, la segunda petición (redirección) sí puede almacenarse en caché. El nuevo URI debe ser devuelto en el campo Location de la respuesta. A menos que se trate de una petición HEAD, la entidad de respuesta debe contener un hipervínculo al nuevo URI y una breve descripción. Nota: Muchos navegadores anteriores a HTTP/1.1 no entienden correctamente el estado 303. Si es necesario considerar la interacción con estos navegadores, el código de estado 302 debería funcionar, ya que la mayoría de los navegadores manejan la respuesta 302 exactamente de la misma forma que la especificación anterior requiere que el cliente maneje la respuesta 303.
304 Este código de estado debe ser devuelto por el servidor si el cliente envía una petición GET condicional y la petición está permitida, y el contenido del documento no ha cambiado (ni desde la última visita ni según las condiciones de la petición). Está prohibido que las respuestas 304 contengan un cuerpo de mensaje, por lo que siempre terminan con la primera línea en blanco después de la cabecera del mensaje. La respuesta debe contener la siguiente información de cabecera: Fecha, a menos que el servidor no disponga de reloj. Si un servidor sin reloj sigue estas reglas, entonces el servidor proxy y el cliente pueden añadir el campo Fecha a la cabecera de respuesta entrante por su cuenta (como se especifica en RFC 2068), y el mecanismo de almacenamiento en caché funcionará correctamente.ETag y/o Content-Location, si la misma petición debería haber devuelto una respuesta 200. Expires, Cache-Control, y/o Vary, si sus valores pueden ser diferentes de los valores de otras respuestas anteriores con las mismas variables. Si la solicitud de respuesta utiliza una validación de caché fuerte, entonces la respuesta no debería contener cabeceras de entidad adicionales; en caso contrario (por ejemplo, una solicitud GET condicional utiliza una validación de caché débil), se prohíbe que la respuesta contenga cabeceras de entidad adicionales; esto evita incoherencias entre el contenido de entidad almacenado en caché y la información de cabecera de entidad actualizada. Si una respuesta 304 indica que una entidad no está actualmente almacenada en caché, el sistema de almacenamiento en caché debe ignorar la respuesta y repetir la solicitud sin la restricción. Si se recibe una respuesta 304 solicitando que se actualice una entrada de la caché, el sistema de caché DEBE actualizar toda la entrada para reflejar los valores de todos los campos actualizados en la respuesta.
305 Se debe acceder al recurso solicitado a través de un proxy especificado. El campo Ubicación proporcionará información sobre el URI del proxy especificado, y el destinatario deberá enviar una solicitud distinta repetidamente para acceder al recurso a través de este proxy. Sólo el servidor original puede crear una respuesta 305. Nota: No está claro en el RFC 2068 que una respuesta 305 esté pensada para redirigir una única petición y que sólo pueda ser creada por el servidor de origen. Ignorar estas restricciones puede tener graves consecuencias para la seguridad.
306 En la última versión de la especificación, el código de estado 306 ya no se utiliza.
307 Ahora, los recursos solicitados responden temporalmente a peticiones procedentes de URI diferentes. Dado que esta redirección es temporal, los clientes deben seguir enviando futuras peticiones a la dirección original. Esta respuesta sólo es almacenable en caché si se especifica en Cache-Control o Expires. El nuevo URI temporal debe devolverse en el campo Location de la respuesta. A menos que se trate de una petición HEAD, la entidad de respuesta debe contener un hipervínculo al nuevo URI y una breve descripción. Dado que algunos navegadores no reconocen la respuesta 307, es necesario añadir la información anterior para que el usuario pueda entender y solicitar el acceso al nuevo URI. Si no se trata de una solicitud GET o HEAD, el navegador prohíbe la redirección automática, salvo confirmación del usuario, porque las condiciones de la solicitud pueden cambiar.
400 1, error semántico, la petición actual no puede ser entendida por el servidor. A menos que se modifique, el cliente no debe repetir la solicitud. 2, los parámetros de la solicitud son erróneos.
401 La solicitud actual requiere la autenticación del usuario. La respuesta debe contener una cabecera WWW-Authenticate para el recurso solicitado para pedir información del usuario. El cliente puede volver a enviar una solicitud con la información de cabecera de autorización adecuada. Si la solicitud actual ya contiene credenciales de Autorización, entonces una respuesta 401 significa que el servidor verifica que esas credenciales han sido rechazadas. Si la respuesta 401 contiene la misma consulta de autenticación que la respuesta anterior, y el navegador ya ha realizado al menos un intento de autenticación, entonces el navegador debería mostrar al usuario la información de entidad contenida en la respuesta, ya que esta información de entidad puede contener información de diagnóstico relevante. Ver RFC 2617.
402 Este código de estado está reservado para posibles requerimientos futuros.
403 El servidor ha entendido la petición, pero se niega a ejecutarla. A diferencia de una respuesta 401, la autenticación no proporciona ninguna ayuda, y la petición no debe ser reenviada. Si no se trata de una petición HEAD, y el servidor quiere ser capaz de decir por qué la petición no puede ser ejecutada, entonces la razón de la denegación debe ser descrita en la entidad. Por supuesto, el servidor también puede devolver una respuesta 404 si no quiere que el cliente obtenga ninguna información.
404 La petición ha fallado, el recurso solicitado no se ha encontrado en el servidor. No hay información que indique al usuario si la situación es temporal o permanente. Si el servidor es consciente de la situación, debe utilizar el código de estado 410 para informar al servidor de que el recurso anterior no está disponible de forma permanente debido a algún mecanismo de configuración interna y que no hay ninguna redirección disponible. 404 se utiliza mucho cuando el servidor no quiere revelar por qué se rechazó la solicitud o cuando no hay ninguna otra respuesta adecuada disponible.
405 El método de solicitud especificado en la línea de solicitud no puede utilizarse para solicitar el recurso correspondiente. La respuesta debe devolver una cabecera Allow que indique la lista de métodos de solicitud aceptables para el recurso actual. Dado que los métodos PUT y DELETE escriben en el recurso en el servidor, la mayoría de los servidores web no los admiten o permiten por defecto y devolverán un error 405 para dichas solicitudes.
406 Las características del contenido del recurso solicitado no satisfacen las condiciones de la cabecera de la petición y no se puede generar una entidad de respuesta. A menos que se trate de una petición HEAD, la respuesta debe devolver una entidad que contenga las características de entidad más apropiadas y una lista de direcciones entre las que el usuario o el navegador puedan elegir. El formato de la entidad viene determinado por el tipo de medio definido en la cabecera Content-Type. El navegador puede hacer la mejor elección basándose en el formato y en sus propias capacidades. Sin embargo, la especificación no define ningún criterio para realizar estas elecciones automáticas.
407 Similar a la respuesta 401, excepto que el cliente debe autenticarse con el servidor proxy. El servidor proxy DEBE devolver un Proxy-Authenticate para la interrogación de identidad. El cliente puede devolver una cabecera Proxy-Authorisation para autenticación. Véase RFC 2617.
408 Tiempo de espera de la solicitud. El cliente no ha completado la solicitud en el 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 La solicitud no pudo completarse debido a un conflicto con el estado actual del recurso solicitado. Sólo se permite utilizar este código si el usuario se considera capaz de resolver el conflicto y volver a enviar una nueva solicitud. La respuesta debe contener información suficiente para que el usuario descubra el origen del conflicto. Los conflictos se producen a menudo en el procesamiento de las solicitudes PUT. Por ejemplo, en un entorno de comprobación de versiones, una solicitud PUT enviada para modificar un determinado recurso con información de versión que entra en conflicto con una solicitud anterior (de terceros) debería devolver un error 409 informando al usuario de que la solicitud no ha podido completarse. En este caso, es probable que la entidad de respuesta contenga una comparación de las diferencias entre las dos versiones en conflicto, para que el usuario pueda volver a enviar la nueva versión fusionada.
410 El recurso solicitado ya no está disponible en el servidor y no se conoce ninguna dirección de reenvío. Esta situació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, entonces se debe utilizar un código de estado 404. A menos que se especifique lo contrario, esta respuesta es almacenable en caché. El propósito de la respuesta 410 es principalmente ayudar al webmaster a mantener el sitio informando al usuario de que el recurso ya no está disponible y que el propietario del servidor desea que todas las conexiones remotas al recurso sean eliminadas también. Este tipo de evento es común en servicios de valor añadido de tiempo limitado. Del mismo modo, la respuesta 410 se utiliza para notificar al cliente que un recurso perteneciente a un individuo ya no está disponible en el sitio actual del servidor. Por supuesto, la cuestión de si todos los recursos no disponibles permanentemente deben marcarse como tales, y cuánto tiempo deben mantenerse así, también es importante.'410 Gone'， y cuánto tiempo debe mantenerse depende enteramente del propietario del servidor.
411 El servidor se niega a aceptar peticiones sin la cabecera Content-Length definida. El cliente puede volver a enviar la solicitud tras añadir una cabecera Content-Length válida que indique la longitud del cuerpo del mensaje de solicitud.
412 El servidor no ha podido satisfacer uno o varios de los requisitos previos indicados en el campo de cabecera de la solicitud al validarla. Este código de estado permite al cliente establecer condiciones previas en la metainformación de la petición (datos del campo de cabecera de la petición) al obtener un recurso, impidiendo así que el método de petición se aplique a recursos distintos del contenido que desea.
413 El servidor se niega a procesar la petición actual porque presenta más datos físicos de los que el servidor está dispuesto o es capaz de manejar. En este caso, el servidor puede cerrar la conexión para evitar que el cliente siga enviando la solicitud. Si la situación es temporal, el servidor debe devolver una cabecera Retry-After para informar al cliente de cuánto tiempo dispone para volver a intentarlo.
414 El URI de la petición es más largo de lo que el servidor puede interpretar, por lo que el servidor se niega a servir la petición. Esto es poco frecuente, y suele ocurrir cuando el envío de un formulario que debería haber utilizado el método POST se convierte en un método GET, lo que da lugar a una cadena de consulta larga. Los "agujeros negros" de URI de redireccionamiento, como el uso del URI antiguo como parte del nuevo URI para cada redireccionamiento, lo que da como resultado un URI largo después de varios redireccionamientos. Los clientes intentan atacar a los servidores aprovechando las vulnerabilidades de seguridad que existen en algunos servidores. Dichos servidores utilizan un búfer de longitud fija para leer o manipular el URI solicitado, lo que puede provocar un desbordamiento del búfer cuando el parámetro GET supera un determinado valor, dando lugar a la ejecución de código arbitrario.[1]。 Los servidores sin este tipo de vulnerabilidades deberían devolver un código de estado 414.
415 Para el método actualmente solicitado y el recurso solicitado, la entidad enviada en la petición no está en un formato soportado por el servidor y la petición es rechazada.
416 Si la petición contiene una cabecera de petición Range, y cualquier rango de datos especificado en Range no coincide con los rangos disponibles para el recurso actual, y la petición no define una cabecera de petición If-Range, entonces el servidor debería devolver un código de estado 416. Si Range utiliza rangos de bytes, significa que el primer byte de todos los rangos de datos especificados en la solicitud supera la longitud del recurso actual. El servidor también debe incluir una cabecera de entidad Content-Range que especifique la longitud del recurso actual junto con el código de estado 416. Esta respuesta tampoco puede utilizar multipart/byteranges como Content-Type.
417 El contenido esperado especificado en la cabecera de la petición Expect no puede ser cumplido por el servidor, o el servidor es un servidor proxy que tiene evidencias claras de que el contenido de Expect no puede ser cumplido en el siguiente nodo de la ruta actual.
421 El número de conexiones al servidor desde la dirección IP del cliente actual excede el máximo permitido por el servidor. Normalmente, la dirección IP se refiere aquí a la dirección del cliente vista desde el servidor (por ejemplo, la dirección de la puerta de enlace o del servidor proxy del usuario). En este caso, más de un usuario final puede estar implicado en el recuento de conexiones.
422 El número de conexiones desde la dirección IP del cliente actual al servidor excede el máximo permitido por el servidor. Normalmente, la dirección IP se refiere aquí a la dirección del cliente vista desde el servidor (por ejemplo, la dirección de la puerta de enlace o del servidor proxy del usuario). En este caso, puede haber más de un usuario final implicado en el recuento de conexiones.
422 La solicitud se formateó correctamente, pero no se pudo responder a ella porque contenía errores semánticos. (RFC 4918 WebDAV) 423 Bloqueado El recurso actual está bloqueado. (RFC 4918 WebDAV) 423 Bloqueado
424 La solicitud actual falló debido a un error en una solicitud previa, como PROPPATCH. (RFC 4918 WebDAV)
425 Definido en el borrador WebDav Advanced Collections, pero no aparece en el protocolo WebDAV Sequential Collections (RFC 3658).
426 Los clientes deberían cambiar a TLS/1.0. (RFC 2817)
449 Extendido por Microsoft para representar que las peticiones deben ser reintentadas después de que se haya realizado la acción apropiada.
500 El servidor encontró una condición imprevista que le impidió completar el procesamiento de la solicitud. Normalmente, este problema se produce cuando hay un error en el código del programa del servidor.
501 El servidor no admite una función requerida por la solicitud actual. Cuando el servidor no reconoce el método solicitado y no puede soportar su petición de ningún recurso.
502 Un servidor que funciona como pasarela o proxy recibe una respuesta no válida de un servidor ascendente cuando intenta ejecutar una solicitud.
503 El servidor no puede procesar la solicitud debido a una sobrecarga o mantenimiento temporal del servidor. Esta condición es temporal y se restablecerá al cabo de un tiempo. Si se puede esperar un retraso, la respuesta puede incluir una cabecera Retry-After para indicar el retraso. Si no se proporciona esta información Retry-After, el cliente debe tratarla del mismo modo que una respuesta 500. Nota: La existencia del código de estado 503 no significa que el servidor deba utilizarlo si está sobrecargado. Algunos servidores simplemente quieren denegar la conexión al cliente.
504 Un servidor que actúa como pasarela o proxy que intenta realizar una petición no recibe una respuesta oportuna de un servidor ascendente (un servidor identificado por un URI, como HTTP, FTP, LDAP) o de un servidor secundario (como DNS). Nota: Algunos servidores proxy devuelven un error 400 o 500 cuando se agota el tiempo de búsqueda DNS.
505 El servidor no admite, o se niega a admitir, la versión de HTTP utilizada en la solicitud. Esto implica que el servidor no puede o no quiere utilizar la misma versión que el cliente. La respuesta debe contener una entidad que describa por qué no se admite la versión y qué protocolos admite el servidor.
506 Extendido por el Protocolo de Negociación de Contenido Transparente (RFC 2295) para representar una mala configuración interna por parte del servidor: el recurso de Variante de Negociación solicitado está configurado para usarse a sí mismo en la Negociación de Contenido Transparente, y por lo tanto no es un foco apropiado en un proceso de negociación.
507 El servidor no puede almacenar el contenido necesario para satisfacer la solicitud. Esta condición se considera temporal.WebDAV(RFC 4918)
509 El servidor ha alcanzado su límite de ancho de banda. Este no es un código de estado oficial, pero sigue siendo muy utilizado.
510 No se ha satisfecho la política necesaria para obtener el recurso. (RFC 2774)
Acceso a los registros: