Lista de Códigos de Estado HTTP

El cliente debe continuar con su solicitud. Esta respuesta provisional indica que todo hasta ahora está bien y que el cliente debe continuar con la solicitud o ignorarla si ya está terminada.

El servidor está cambiando de protocolos según lo solicitado por el cliente a través de una cabecera de solicitud Upgrade.

WebDAV; El servidor ha recibido y está procesando la solicitud, pero aún no hay respuesta disponible. Esto evita que el cliente agote el tiempo de espera y asuma que la solicitud se perdió.

El servidor está enviando algunas cabeceras antes del mensaje HTTP final. Se utiliza para permitir que el cliente comience a precargar recursos mientras el servidor todavía está preparando la respuesta principal.

La solicitud ha tenido éxito. El significado de 'éxito' depende del método HTTP: GET: El recurso ha sido obtenido y transmitido en el cuerpo del mensaje. HEAD: Las cabeceras de la entidad están en el cuerpo del mensaje. POST o PUT: El recurso que describe el resultado de la acción se transmite en el cuerpo del mensaje. TRACE: El cuerpo del mensaje contiene el mensaje de solicitud tal como lo recibió el servidor.

La solicitud ha sido completada y ha resultado en la creación de un nuevo recurso. El nuevo recurso se crea efectivamente antes de que se envíe esta respuesta y el nuevo recurso se devuelve en el cuerpo del mensaje, siendo su ubicación la URL de la solicitud o el contenido de la cabecera Location.

La solicitud ha sido aceptada para su procesamiento, pero el procesamiento no se ha completado. La solicitud podría o no ser finalmente procesada, ya que podría ser rechazada cuando el procesamiento realmente tenga lugar.

La metainformación devuelta proviene de una copia local o de terceros, no del servidor de origen, y podría ser incorrecta. Excepto en este caso específico, la respuesta 200 OK es preferible a este estado.

El servidor procesó con éxito la solicitud y no devuelve ningún contenido. Útil para acciones que no requieren un cuerpo de respuesta, como una solicitud DELETE.

El servidor procesó con éxito la solicitud, pide que el solicitante restablezca la vista de su documento y no devuelve ningún contenido. A menudo se usa después de enviar un formulario para borrar los campos del formulario para una nueva entrada.

El servidor está entregando solo una parte del recurso (servicio de bytes) debido a una cabecera de rango enviada por el cliente. La cabecera de rango es utilizada por herramientas como wget para permitir la reanudación de descargas interrumpidas o dividir una descarga en múltiples flujos simultáneos.

WebDAV; Transmite información sobre múltiples recursos, para situaciones donde múltiples códigos de estado podrían ser apropiados. El cuerpo es un mensaje XML.

WebDAV; Utilizado dentro de un elemento de respuesta <dav:propstat> para evitar enumerar repetidamente los miembros internos de múltiples enlaces a la misma colección. Los miembros de un enlace ya han sido enumerados en una respuesta anterior.

El servidor ha cumplido una solicitud GET para el recurso, y la respuesta es una representación del resultado de una o más manipulaciones de instancia aplicadas a la instancia actual. (RFC 3229)

Indica múltiples opciones para el recurso entre las cuales el cliente puede elegir (por ejemplo, diferentes formatos de video, lista de archivos con diferentes extensiones). El servidor puede incluir una cabecera Location con una opción preferida.

Esta y todas las futuras solicitudes deben dirigirse a la URI dada. Los motores de búsqueda actualizarán sus enlaces al recurso (en 'lenguaje SEO', se dice que el 'link-juice' se envía a la nueva URL).

Este código de respuesta significa que la URI del recurso solicitado ha sido cambiada temporalmente. Podrían realizarse cambios futuros en la URI. Por lo tanto, esta misma URI debe ser utilizada por el cliente en futuras solicitudes.

El servidor envió esta respuesta para dirigir al cliente a obtener el recurso solicitado en otra URI con una solicitud GET. Típicamente usado después de una operación POST/PUT para evitar que al actualizar la página se reenvíe el formulario.

Indica que el recurso no ha sido modificado desde la versión especificada por las cabeceras de solicitud If-Modified-Since o If-None-Match. En tal caso, no hay necesidad de retransmitir el recurso ya que el cliente todavía tiene una copia previamente descargada.

Obsoleto. El recurso solicitado solo está disponible a través de un proxy, cuya dirección se proporciona en la respuesta. Muchos clientes HTTP (como Mozilla Firefox e Internet Explorer) no manejan correctamente las respuestas con este código de estado, principalmente por razones de seguridad.

El servidor envía esta respuesta para dirigir al cliente a obtener el recurso solicitado en otra URI con el mismo método que se usó en la solicitud anterior. Tiene la misma semántica que el código de respuesta HTTP 302 Found, con la excepción de que el agente de usuario no debe cambiar el método HTTP utilizado.

El recurso ahora se encuentra permanentemente en otra URI, especificada por la cabecera de respuesta HTTP Location:. Tiene la misma semántica que el código de respuesta HTTP 301 Moved Permanently, con la excepción de que el agente de usuario no debe cambiar el método HTTP utilizado: si se usó un POST en la primera solicitud, se debe usar un POST en la segunda solicitud.

El servidor no puede o no procesará la solicitud debido a un aparente error del cliente (p.ej., sintaxis de solicitud malformada, entramado de mensaje de solicitud inválido o enrutamiento de solicitud engañoso).

Se requiere autenticación y ha fallado o aún no se ha proporcionado. La respuesta debe incluir un campo de cabecera WWW-Authenticate que contenga un desafío aplicable al recurso solicitado. A veces se usa para 'Autorización fallida', pero 403 es más apropiado.

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, pero eso aún no ha sucedido, y este código no se usa ampliamente.

La solicitud fue válida, pero el servidor se niega a actuar. Es posible que el usuario no tenga los permisos necesarios para un recurso o necesite algún tipo de cuenta.

El recurso solicitado no pudo ser encontrado pero podría estar disponible en el futuro. Las solicitudes posteriores por parte del cliente son permisibles. A menudo se usa cuando un servidor no desea revelar exactamente por qué se ha rechazado una solicitud, o cuando ninguna otra respuesta es aplicable.

Un método de solicitud no es compatible con 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.

El recurso solicitado solo es capaz de generar contenido no aceptable según las cabeceras Accept enviadas en la solicitud. Por ejemplo, el cliente solicitó XML, pero el servidor solo puede proporcionar JSON.

El cliente primero debe autenticarse con el proxy. El proxy debe enviar un campo de cabecera Proxy-Authenticate que contenga un desafío aplicable al proxy para el recurso solicitado.

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.'

Indica que la solicitud no pudo ser procesada debido a un conflicto en el estado actual del recurso, como un conflicto de edición entre múltiples actualizaciones simultáneas.

Indica que el recurso solicitado ya no está disponible y no volverá a estarlo. Esto debe usarse cuando un recurso ha sido eliminado intencionalmente y el recurso debe ser purgado. Al recibir un código de estado 410, el cliente no debe solicitar el recurso en el futuro.

La solicitud no especificó la longitud de su contenido, lo cual es requerido por el recurso solicitado. El servidor no aceptará la solicitud sin una cabecera Content-Length válida.

El servidor no cumple una de las precondiciones que el solicitante puso en los campos de cabecera de la solicitud. Esto se usa a menudo con solicitudes GET condicionales (usando cabeceras If-Match o If-Unmodified-Since).

La solicitud es más grande de lo que el servidor está dispuesto o es capaz de procesar. Anteriormente llamado 'Entidad de Solicitud Demasiado Grande'.

La URI proporcionada era demasiado larga para que el servidor la procesara. A menudo es el resultado de demasiados datos codificados como una cadena de consulta de una solicitud GET, en cuyo caso debe convertirse en una solicitud POST. Anteriormente llamado 'Request-URI Too Long'.

La entidad de la solicitud tiene un tipo de medio que el servidor o el recurso no soporta. Por ejemplo, el cliente carga una imagen como image/svg+xml, pero el servidor requiere que las imágenes usen un formato diferente.

El cliente ha solicitado una porción del archivo (servicio de bytes), pero el servidor no puede suministrar esa porción. Por ejemplo, si el cliente solicitó una parte del archivo que se encuentra más allá del final del archivo. Anteriormente llamado 'Rango Solicitado No Satisfactorio'.

El servidor no puede cumplir con los requisitos del campo de cabecera de solicitud Expect. El cliente envió una cabecera Expect (p.ej., Expect: 100-continue) que el servidor no puede cumplir.

Este código fue definido en 1998 como una broma del Día de los Inocentes en RFC 2324, Hyper Text Coffee Pot Control Protocol (HTCPCP/1.0), y no se espera que sea implementado por servidores HTTP reales. Sin embargo, a veces se usa como un 'huevo de pascua'.

La solicitud fue dirigida a un servidor que no puede producir una respuesta. Esto puede ser enviado por un servidor que no está configurado para producir respuestas para la combinación de esquema y autoridad que se incluyen en la URI de la solicitud.

WebDAV; La solicitud estaba bien formada pero no pudo ser seguida debido a errores semánticos. Por ejemplo, un cuerpo de solicitud XML contiene instrucciones XML bien formadas (es decir, sintácticamente correctas), pero semánticamente erróneas.

WebDAV; El recurso al que se está accediendo está bloqueado. Esto significa que el recurso de origen o destino de un método está bloqueado.

WebDAV; La solicitud falló porque dependía de otra solicitud y esa solicitud falló (p.ej., un PROPPATCH con un PROPFIND que falló).

El cliente debe cambiar a un protocolo diferente como TLS/1.0, indicado en el campo de cabecera Upgrade. El servidor envía una cabecera Upgrade con esta respuesta para indicar el/los protocolo(s) requerido(s).

El servidor de origen requiere que la solicitud sea condicional. Destinado a prevenir el problema de 'actualización perdida', donde 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 lleva a un conflicto.

El usuario ha enviado demasiadas solicitudes en un período de tiempo determinado ('limitación de velocidad'). Las representaciones de respuesta DEBERÍAN incluir detalles que expliquen la condición, y PUEDEN incluir una cabecera Retry-After que indique cuánto tiempo esperar antes de realizar una nueva solicitud.

El servidor no está dispuesto a procesar la solicitud porque sus campos de cabecera son demasiado grandes. La solicitud PUEDE ser reenviada después de reducir el tamaño de los campos de cabecera de la solicitud.

El servidor niega el acceso al recurso como consecuencia de una demanda legal. Esto podría ser una censura gubernamental o una orden judicial.

Un mensaje de error genérico, dado cuando se encuentra una condición inesperada y ningún mensaje más específico es adecuado. Este es un error del lado del servidor 'para todo'.

El servidor no reconoce el método de solicitud o carece de la capacidad para cumplir con la solicitud. Usualmente esto implica disponibilidad futura (p.ej., una nueva característica de una API de servicio web).

El servidor actuaba como una puerta de enlace o proxy y recibió una respuesta inválida del servidor ascendente al que accedió al intentar cumplir la solicitud.

El servidor no está disponible actualmente (porque está sobrecargado o en mantenimiento). Generalmente, este es un estado temporal. Se podría incluir una cabecera Retry-After para sugerir una demora.

El servidor actuaba como una puerta de enlace o proxy y no recibió una respuesta oportuna del servidor ascendente o algún otro servidor auxiliar al que necesitaba acceder para completar la solicitud.

El servidor no soporta la versión del protocolo HTTP utilizada en la solicitud. La respuesta debería contener una entidad que describa por qué esa versión no es soportada y qué otros protocolos son soportados por ese servidor.

La negociación de contenido transparente para la solicitud resulta en una referencia circular. El recurso variante elegido está configurado para participar en la negociación de contenido transparente él mismo y, por lo tanto, no es un punto final adecuado en el proceso de negociación.

WebDAV; El servidor no puede almacenar la representación necesaria para completar la solicitud. Esta condición se considera temporal.

WebDAV; El servidor detectó un bucle infinito mientras procesaba la solicitud (enviado en lugar de 208 Ya Reportado). Esto indica que toda la operación falló.

Se requieren extensiones adicionales a la solicitud para que el servidor la cumpla. La solicitud requiere una extensión obligatoria que no es soportada por el servidor.

El cliente necesita autenticarse para obtener acceso a la red. Destinado al uso por proxies de intercepción utilizados para controlar el acceso a la red (p.ej., 'portales cautivos' utilizados para requerir la aceptación de los Términos de Servicio antes de otorgar acceso completo a Internet a través de un punto de acceso Wi-Fi).