Consejo: Ctrl+F para buscar rápido| Código de estado Http | Significado del código de estado |
|---|---|
| 100 | El cliente debe seguir enviando la solicitud. Esta respuesta temporal notifica al cliente que el servidor ha recibido parte de su solicitud y no la ha rechazado. El cliente debe seguir enviando el resto de la solicitud o, si ya está completa, ignorar esta respuesta. El servidor debe enviar al cliente una respuesta final al completar la solicitud. |
| 101 | El servidor ha entendido la solicitud del cliente y, mediante la cabecera Upgrade, le avisará de que use un protocolo diferente para completarla. Tras enviar la última línea vacía de esta respuesta, el servidor cambiará a los protocolos definidos en la cabecera Upgrade. Estas medidas solo deben tomarse cuando cambiar a un nuevo protocolo aporte ventajas, por ejemplo a una versión HTTP más ventajosa que la anterior, o a un protocolo en tiempo real y sincrónico para transmitir recursos que aprovechen dichas características. |
| 102 | Un código de estado añadido por la extensión WebDAV (RFC 2518), que significa que el procesamiento continuará. |
| 200 | La solicitud se completó correctamente; los encabezados de respuesta o el cuerpo de datos deseados se enviarán con esta respuesta. |
| 201 | La solicitud se ha cumplido y se ha creado un nuevo recurso según lo solicitado, y su URI se ha devuelto en la cabecera Location. Si el recurso no puede crearse a tiempo, debe devolverse '202 Accepted'. |
| 202 | El servidor ha aceptado la solicitud, pero aún no la ha procesado. Al igual que podría ser rechazada, la solicitud puede ejecutarse o no finalmente. En operaciones asíncronas, no hay nada más práctico que enviar este código de estado. El objetivo de una respuesta 202 es permitir que el servidor acepte solicitudes de otros procesos (por ejemplo, una operación por lotes que se ejecuta solo una vez al día) sin que el cliente mantenga la conexión hasta que el lote termine. La respuesta que acepta la solicitud y devuelve el código 202 debe incluir en la entidad información sobre el estado actual del procesamiento y un puntero a un monitor o previsión de estado para que el usuario pueda estimar si la operación ya terminó. |
| 203 | El servidor procesó correctamente la solicitud, pero los metadatos de la cabecera de entidad devuelta no son un conjunto definitivo válido en el servidor original, sino una copia local o de terceros. La información actual puede ser un subconjunto o un superconjunto de la versión original. Por ejemplo, los metadatos del recurso podrían hacer que el servidor original conozca un superconjunto de los metadatos. El uso de este código de estado no es obligatorio y solo es adecuado cuando la respuesta devolvería 200 OK sin este código. |
| 204 | El servidor procesó correctamente la solicitud, pero no necesita devolver contenido de entidad y desea devolver metainformación actualizada. La respuesta puede devolver metadatos nuevos o actualizados mediante cabeceras de entidad. Si existen dichas cabeceras, deben corresponder a las variables solicitadas. Si el cliente es un navegador, este debe conservar la página que envió la solicitud sin ningún cambio en la vista del documento, aunque según la especificación los metadatos nuevos o actualizados deban aplicarse al documento de la vista activa. Como la respuesta 204 no puede incluir cuerpo de mensaje, siempre termina con la primera línea vacía tras las cabeceras del mensaje. |
| 205 | El servidor procesó correctamente la solicitud y no devolvió ningún contenido. Pero a diferencia de la respuesta 204, la respuesta con este código de estado exige que el solicitante restablezca la vista del documento. Se usa sobre todo para restablecer el formulario inmediatamente después de aceptar la entrada del usuario, para que pueda empezar fácilmente otra entrada. Al igual que la respuesta 204, esta respuesta tampoco puede contener ningún cuerpo de mensaje y termina con la primera línea vacía tras las cabeceras del mensaje. |
| 206 | El servidor ha procesado correctamente una solicitud GET parcial. Las herramientas de descarga HTTP como FlashGet o Thunder usan este tipo de respuesta para implementar la reanudación de descargas o para dividir un documento grande en varios segmentos de descarga simultánea. La solicitud debe incluir el encabezado Range para indicar el rango de contenido que el cliente desea obtener, y puede incluir If-Range como condición de solicitud. La respuesta debe incluir los siguientes campos de cabecera: Content-Range para indicar el rango de contenido devuelto en esta respuesta; si es una descarga multiparte con Content-Type multipart/byteranges, cada segmento multipart debe incluir un campo Content-Range que indique el rango de contenido de ese segmento. Si la respuesta incluye Content-Length, su valor debe coincidir con el número real de bytes del rango de contenido devuelto. Date, 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 los de otras respuestas anteriores a la misma variable. Si la solicitud de esta respuesta usó la validación de caché fuerte If-Range, esta respuesta no debe incluir otros encabezados de entidad; si la solicitud de esta respuesta usó la validación de caché débil If-Range, esta respuesta no debe incluir otros encabezados de entidad; esto evita la inconsistencia entre el contenido de la entidad en caché y los encabezados de entidad actualizados. De lo contrario, esta respuesta debe incluir todos los encabezados de entidad que una respuesta 200 debería haber devuelto. Si los encabezados ETag o Last-Modified no coinciden exactamente, la caché del cliente no debe combinar el contenido devuelto por la respuesta 206 con ningún contenido previamente almacenado en caché. Cualquier caché que no admita los encabezados Range y Content-Range no debe almacenar en caché el contenido devuelto por una respuesta 206. |
| 207 | Código de estado ampliado por WebDAV (RFC 2518) que indica que el cuerpo del mensaje siguiente será un mensaje XML, que quizá contenga una serie de códigos de respuesta independientes según el número de subconsultas previas. |
| 300 | El recurso solicitado ofrece un conjunto de respuestas seleccionables, cada una con su propia dirección específica e información de negociación impulsada por el navegador. El usuario o el navegador pueden elegir una dirección preferida a la que redirigir. A menos que sea una solicitud HEAD, la respuesta debe incluir una entidad que sea una lista de las características y direcciones del recurso, para que el usuario o el navegador puedan seleccionar la dirección de redirección más adecuada. El formato de esta entidad viene determinado por el formato definido por Content-Type. El navegador puede realizar automáticamente la selección más adecuada según el formato de la respuesta y sus propias capacidades. Por supuesto, la especificación RFC 2616 no define cómo debe realizarse dicha selección automática. Si el servidor ya tiene una opción de respuesta preferida, el campo Location debe indicar el URI de esa opción; el navegador puede usar este valor de Location como la dirección para la redirección automática. Además, salvo indicación contraria, esta respuesta también es almacenable en caché. |
| 301 | El recurso solicitado se ha movido permanentemente a una nueva ubicación, y cualquier referencia futura a este recurso debe usar uno de los URI devueltos por esta respuesta. Si es posible, cualquier cliente con función de edición de enlaces debe cambiar automáticamente la dirección de la solicitud a la que devuelve el servidor. Salvo indicación contraria, esta respuesta es almacenable en caché. El nuevo URI permanente debe devolverse en el campo Location de la respuesta. A menos que sea una solicitud HEAD, la entidad de la respuesta debe incluir un hipervínculo al nuevo URI y una breve descripción. Si no es una solicitud GET o HEAD, el navegador no debe redirigir automáticamente salvo que el usuario lo confirme, porque las condiciones de la solicitud pueden cambiar como resultado. Nota: para algunos navegadores que usan el protocolo HTTP/1.0, cuando la solicitud POST que enviaron recibe una respuesta 301, la solicitud de redirección posterior pasará a ser una solicitud GET. |
| 302 | El recurso solicitado se sirve temporalmente desde un URI diferente. Dado que esta redirección es temporal, el cliente debe seguir enviando las solicitudes futuras a la dirección original. Esta respuesta solo 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 sea una solicitud HEAD, la entidad de la respuesta debe incluir un hipervínculo al nuevo URI y una breve descripción. Si no es una solicitud GET o HEAD, el navegador no debe redirigir automáticamente salvo que el usuario lo confirme, porque las condiciones de la solicitud pueden cambiar como resultado. Nota: aunque las especificaciones RFC 1945 y RFC 2068 no permiten al cliente cambiar el método de solicitud al redirigir, muchos navegadores existentes tratan la respuesta 302 como una respuesta 303 y usan GET para acceder al URI especificado en Location, ignorando el método de solicitud original. Los códigos de estado 303 y 307 se añadieron para dejar claro cómo espera el servidor que reaccione el cliente. |
| 303 | La respuesta a la solicitud actual puede encontrarse en un URI diferente y el cliente debe acceder a ese recurso usando GET. Este método existe principalmente para permitir que la salida de una solicitud POST activada por un script se redirija a un nuevo recurso. El nuevo URI no es una referencia sustituta del recurso original. Además, la respuesta 303 no debe almacenarse en caché. Por supuesto, la segunda solicitud (la redirección) puede ser almacenable. El nuevo URI debe devolverse en el campo Location de la respuesta. A menos que sea una solicitud HEAD, la entidad de la respuesta debe incluir un hipervínculo al nuevo URI y una breve descripción. Nota: muchos navegadores anteriores a HTTP/1.1 no interpretan correctamente el estado 303. Si se debe considerar la interacción con estos navegadores, el código de estado 302 debería ser suficiente, ya que la forma en que la mayoría de los navegadores manejan la respuesta 302 es exactamente lo que la especificación anterior exige al cliente hacer al manejar una respuesta 303. |
| 304 | Si el cliente ha enviado una solicitud GET condicional y dicha solicitud ha sido permitida, pero el contenido del documento no ha cambiado (desde el último acceso o según las condiciones de la solicitud), el servidor debe devolver este código de estado. La respuesta 304 no debe incluir un cuerpo de mensaje y por tanto siempre termina tras la primera línea en blanco después de las cabeceras. La respuesta debe incluir los siguientes campos de cabecera: Date, a menos que el servidor no tenga reloj. Si un servidor sin reloj también respeta estas reglas, los servidores proxy y los clientes pueden añadir por sí mismos el campo Date a las cabeceras de respuesta recibidas (como se especifica en RFC 2068), y el mecanismo de 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 los de otras respuestas anteriores a la misma variable. Si la solicitud de esta respuesta usó la validación de caché fuerte, esta respuesta no debe incluir otros encabezados de entidad; en caso contrario (por ejemplo, si una solicitud GET condicional usó la validación de caché débil), esta respuesta no debe incluir otros encabezados de entidad; esto evita la inconsistencia entre el contenido de la entidad en caché y los encabezados de entidad actualizados. Si una respuesta 304 indica que actualmente una entidad no está en caché, el sistema de caché debe ignorar esa respuesta y repetir la solicitud sin condiciones. Si se recibe una respuesta 304 que requiere actualizar una entrada de caché, el sistema de caché debe actualizar toda la entrada para reflejar los valores de todos los campos actualizados en la respuesta. |
| 305 | El recurso solicitado debe accederse a través del proxy especificado. El campo Location proporciona la URI del proxy indicado, y el receptor debe repetir una solicitud aparte a través de ese proxy para acceder al recurso. Solo el servidor de origen puede crear una respuesta 305. Nota: el RFC 2068 no deja claro que la respuesta 305 sirve para redirigir una solicitud aparte y que solo puede crearla el servidor de origen. Ignorar estas restricciones puede tener graves consecuencias de seguridad. |
| 306 | En la última versión de la especificación, el código de estado 306 ya no se usa. |
| 307 | El recurso solicitado se sirve temporalmente desde un URI diferente. Dado que esta redirección es temporal, el cliente debe seguir enviando las solicitudes futuras a la dirección original. Esta respuesta solo 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 sea una solicitud HEAD, la entidad de la respuesta debe incluir un hipervínculo al nuevo URI y una breve descripción. Como algunos navegadores no reconocen la respuesta 307, es necesario añadir la información necesaria indicada para que el usuario pueda comprenderla y enviar una solicitud al nuevo URI. Si no es una solicitud GET o HEAD, el navegador no debe redirigir automáticamente salvo que el usuario lo confirme, porque las condiciones de la solicitud pueden cambiar como resultado. |
| 400 | 1. La solicitud no puede ser entendida por el servidor por sintaxis incorrecta; el cliente no debe repetirla sin modificaciones. 2. Los parámetros de la solicitud son incorrectos. |
| 401 | La solicitud actual requiere autenticación de usuario. La respuesta debe incluir un campo de cabecera WWW-Authenticate aplicable al recurso solicitado para solicitar información al usuario. El cliente puede reenviar una solicitud que contenga un encabezado Authorization adecuado. Si la solicitud actual ya contenía credenciales de Authorization, la respuesta 401 significa que la validación del servidor ha rechazado dichas credenciales. Si una respuesta 401 contiene el mismo desafío de autenticación que una respuesta anterior y el navegador ya ha intentado la autenticación al menos una vez, el navegador debe mostrar al usuario la información de entidad incluida en la respuesta, porque esa información de entidad puede contener información diagnóstica relevante. Consulte RFC 2617. |
| 402 | Este código de estado está reservado para posibles necesidades futuras. |
| 403 | El servidor ha entendido la solicitud pero se niega a ejecutarla. A diferencia de la respuesta 401, la autenticación no ayuda en nada y la solicitud no debe repetirse. Si no es una solicitud HEAD y el servidor quiere dejar claro por qué no puede ejecutarse, debe describirse el motivo en la entidad. El servidor también puede devolver una respuesta 404 si no quiere que el cliente obtenga ninguna información. |
| 404 | La solicitud falló; el recurso esperado no se encontró en el servidor. Ninguna información indica si la situación es temporal o permanente. Si el servidor conoce la situación, debe usar el código 410 para indicar que el recurso antiguo es permanentemente indisponible por algún problema interno de configuración y que no existe dirección de redirección alguna. El código 404 se usa ampliamente cuando el servidor no quiere revelar por qué rechazó la solicitud o cuando no hay otra respuesta adecuada disponible. |
| 405 | El método de solicitud indicado en la línea de solicitud no puede usarse para solicitar el recurso correspondiente. Esta respuesta debe devolver una cabecera Allow que indique la lista de métodos de solicitud que acepta el recurso actual. Dado que los métodos PUT y DELETE realizan operaciones de escritura sobre los recursos del servidor, la mayoría de los servidores web no admiten esos métodos de solicitud o no los permiten con la configuración predeterminada, y devuelven un error 405 para todas esas solicitudes. |
| 406 | Las características del contenido del recurso solicitado no satisfacen las condiciones de las cabeceras de la solicitud, por lo que no se puede generar una entidad de respuesta. Salvo que sea una solicitud HEAD, la respuesta debe devolver una entidad con una lista de características y direcciones de entidad para que el usuario o el navegador elija la más adecuada. El formato de la entidad lo determina el tipo de medio definido en la cabecera Content-Type. El navegador puede elegir lo mejor según el formato y sus propias capacidades, pero la especificación no define ningún estándar para realizar dicha selección automática. |
| 407 | Similar a la respuesta 401, salvo que el cliente debe autenticarse ante el servidor proxy. El servidor proxy debe devolver un Proxy-Authenticate para realizar el desafío de autenticación. El cliente puede devolver un encabezado Proxy-Authorization para autenticarse. Consulte RFC 2617. |
| 408 | Tiempo de espera de la solicitud agotado. El cliente no completó el envío de una solicitud dentro del tiempo que el servidor estaba dispuesto a esperar. El cliente puede volver a enviar la solicitud en cualquier momento sin cambios. |
| 409 | La solicitud no pudo completarse debido a un conflicto con el estado actual del recurso solicitado. Este código solo debe usarse en situaciones en las que se espera que el usuario pueda resolver el conflicto y reenviar una nueva solicitud. La respuesta debe incluir información suficiente para que el usuario descubra el origen del conflicto. Los conflictos suelen producirse durante el procesamiento de solicitudes PUT. Por ejemplo, en un entorno que usa comprobación de versiones, si la información de versión adjunta a una solicitud PUT que modifica un recurso específico entra en conflicto con la de una solicitud (de terceros) anterior, el servidor debe devolver un error 409 para indicar al usuario que la solicitud no puede completarse. En ese caso, es probable que la entidad de la respuesta incluya una comparación de las diferencias entre las dos versiones en conflicto, para que el usuario reenvíe una nueva versión ya 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, cualquier cliente con función de edición de enlaces debe, con el permiso del usuario, eliminar todas las referencias a esta dirección. Si el servidor no sabe o no puede determinar si la situación es permanente, debe usarse el código de estado 404. Salvo indicación contraria, esta respuesta es almacenable en caché. El propósito de la respuesta 410 es principalmente ayudar a los administradores web a mantener sus sitios, notificando a los usuarios que el recurso ya no está disponible y que el propietario del servidor desea que se eliminen todos los enlaces remotos a este recurso. Este tipo de situación es común en servicios de valor añadido por tiempo limitado. Del mismo modo, la respuesta 410 se usa para informar al cliente de que un recurso que originalmente pertenecía a una persona en el sitio del servidor actual ya no está disponible. Por supuesto, si se deben marcar todos los recursos permanentemente no disponibles como '410 Gone', y durante cuánto tiempo debe mantenerse ese marcaje, depende totalmente del propietario del servidor. |
| 411 | El servidor rechaza la solicitud sin una cabecera Content-Length definida. Tras añadir una cabecera Content-Length válida que indique la longitud del cuerpo de la solicitud, el cliente puede volver a enviarla. |
| 412 | El servidor no pudo cumplir una o más de las precondiciones indicadas en los campos de cabecera de la solicitud al validarlas. Este código de estado permite al cliente establecer precondiciones en la metainformación de la solicitud (campos de cabecera de la solicitud) antes de obtener el recurso, para evitar aplicar el método de solicitud a otros contenidos distintos del recurso deseado. |
| 413 | El servidor rechaza procesar la solicitud actual porque el tamaño de los datos de entidad enviados por la solicitud supera el rango que el servidor está dispuesto o puede procesar. En este caso el servidor puede cerrar la conexión para evitar que el cliente siga enviando esta solicitud. Si la situación es temporal, el servidor debería devolver una cabecera de respuesta Retry-After para indicar al cliente cuánto tiempo debe esperar antes de reintentarlo. |
| 414 | La longitud del URI de la solicitud supera la que el servidor puede interpretar, por lo que el servidor rechaza atender la solicitud. Esto es poco frecuente; entre las situaciones habituales se incluyen: un envío de formulario que debía usar el método POST se convierte en una solicitud GET, lo que produce una cadena de consulta (Query String) demasiado larga. Un URI de redirección "agujero negro", por ejemplo, cuando cada redirección añade el URI anterior como parte del nuevo URI, lo que hace que el URI supere el límite tras varias redirecciones. El cliente está intentando atacar el servidor explotando una vulnerabilidad de seguridad presente en ciertos servidores. Este tipo de servidores lee o manipula el URI de la solicitud mediante un búfer de longitud fija; cuando los parámetros después de GET superan cierto valor, puede producirse un desbordamiento de búfer que provoque la ejecución de código arbitrario[1]. Un servidor sin dicha vulnerabilidad debería devolver el código de estado 414. |
| 415 | La entidad enviada en la solicitud no está en un formato admitido por el servidor para el método y el recurso solicitados, por lo que la solicitud se rechaza. |
| 416 | Si la solicitud incluye un encabezado de solicitud Range y ninguno de los rangos de datos especificados en Range coincide con el rango disponible del recurso actual, y además la solicitud no define un encabezado de solicitud If-Range, el servidor debe devolver el código de estado 416. Si Range usa rangos de bytes, esta situación significa que la posición del primer byte de todos los rangos de datos especificados en la solicitud supera la longitud del recurso actual. Al devolver el código de estado 416, el servidor también debe incluir un encabezado de entidad Content-Range que indique la longitud del recurso actual. Tampoco se permite a esta respuesta usar multipart/byteranges como su Content-Type. |
| 417 | El contenido esperado especificado en la cabecera Expect de la solicitud no puede ser satisfecho por el servidor, o el servidor es un proxy con pruebas evidentes de que el contenido de Expect no podrá satisfacerse en el siguiente nodo de la ruta actual. |
| 421 | El número de conexiones desde la dirección IP del cliente actual al servidor supera el máximo permitido por el servidor. Normalmente, la dirección IP es aquí la dirección del cliente tal como la ve el servidor (por ejemplo, la dirección de la pasarela o del servidor proxy del usuario). En este caso, el recuento de conexiones puede afectar a más de un usuario final. |
| 422 | El número de conexiones desde la dirección IP del cliente actual al servidor supera el máximo permitido por el servidor. Normalmente, la dirección IP es aquí la dirección del cliente tal como la ve el servidor (por ejemplo, la dirección de la pasarela o del servidor proxy del usuario). En este caso, el recuento de conexiones puede afectar a más de un usuario final. |
| 422 | La solicitud tiene un formato correcto, pero no puede responderse debido a errores semánticos. (RFC 4918 WebDAV) 423 Locked El recurso actual está bloqueado. (RFC 4918 WebDAV) |
| 424 | La solicitud actual falló por un error en una solicitud anterior, por ejemplo PROPPATCH. (RFC 4918 WebDAV) |
| 425 | Definido en el borrador WebDav Advanced Collections, pero no aparece en el Protocolo de conjuntos ordenados WebDAV (RFC 3658). |
| 426 | El cliente debería cambiar a TLS/1.0. (RFC 2817) |
| 449 | Ampliado por Microsoft: la solicitud debe reintentarse tras realizar la acción adecuada. |
| 500 | El servidor encontró una situación inesperada que le impidió procesar la solicitud. En general, este problema aparece cuando el código del servidor produce un error. |
| 501 | El servidor no admite la funcionalidad requerida por la solicitud. El método de la solicitud no se reconoce y no puede admitirse para ningún recurso. |
| 502 | El servidor, que actúa como gateway o proxy, recibió una respuesta no válida de un servidor upstream al intentar ejecutar la solicitud. |
| 503 | Debido a mantenimiento temporal o sobrecarga del servidor, este no puede procesar la solicitud en este momento. La situación es temporal y se recuperará pasado un tiempo. Si se puede prever el retardo, la respuesta puede incluir una cabecera Retry-After para indicarlo. Si no se da esta información Retry-After, el cliente debe tratar la respuesta como trataría una respuesta 500. Nota: la existencia del código 503 no obliga al servidor a usarlo cuando está sobrecargado; algunos servidores solo desean rechazar conexiones de clientes. |
| 504 | Un servidor que funciona como puerta de enlace o proxy no recibió a tiempo una respuesta de un servidor upstream (el servidor identificado por el URI, p. ej. HTTP, FTP, LDAP) o de un servidor auxiliar (p. ej. DNS) al intentar ejecutar la solicitud. Nota: algunos servidores proxy devuelven un error 400 o 500 cuando una consulta DNS agota el tiempo de espera. |
| 505 | El servidor no admite o se niega a admitir la versión HTTP utilizada en la solicitud. Esto indica que el servidor no puede o no quiere usar la misma versión que el cliente. La respuesta debe incluir una entidad que describa por qué no se admite la versión y qué protocolos admite el servidor. |
| 506 | Ampliado por el Protocolo de negociación transparente de contenido (RFC 2295): el servidor tiene un error interno de configuración: el recurso de variante negociado está configurado para usarse a sí mismo en la negociación transparente de contenido, por lo que no es un destino adecuado dentro de una negociación. |
| 507 | El servidor no puede almacenar el contenido necesario para completar la solicitud. Esta condición se considera temporal. WebDAV (RFC 4918) |
| 509 | El servidor alcanzó el límite de ancho de banda. No es un código de estado oficial, pero sigue usándose ampliamente. |
| 510 | No se cumple la política necesaria para acceder al recurso. (RFC 2774) |
Esta herramienta pertenece a la categoría «Tablas de referencia».
Siempre que es posible, el contenido se procesa en tu propio navegador. No lo guardamos.
Algunas consultas exponen un endpoint JSON; la lista está en Herramientas de red → Referencia de API.
Las especificaciones avanzan. Aquí se recogen las entradas más usadas con la fecha de actualización; avísanos de cualquier error.
Mantenemos solo lo frecuente para que la página pese poco y cargue rápido.