| código de estado HTTP | Significado del código de estado |
|---|
| 100 | El cliente debe continuar enviando solicitudes. Esta respuesta provisional se utiliza para informar al cliente que parte de su solicitud ha sido recibida por el servidor y aún no ha sido rechazada. El cliente DEBE continuar enviando el resto de la solicitud o ignorar esta respuesta si la solicitud ya se ha completado. El servidor debe enviar una respuesta final al cliente una vez completada la solicitud. |
| 101 | El servidor ha entendido la solicitud del cliente y le notificará a través del encabezado del mensaje de actualización que utilice un protocolo diferente para completar la solicitud. Después de enviar la última línea en blanco de esta respuesta, el servidor cambiará a los protocolos definidos en el encabezado Actualización. Estas medidas sólo deben tomarse cuando cambiar a un nuevo protocolo sea más beneficioso. Por ejemplo, cambiar a una nueva versión HTTP tiene ventajas sobre una versión anterior, o cambiar a un protocolo sincrónico y en tiempo real para entregar recursos que aprovechen dichas características. |
| 102 | Un código de estado extendido por WebDAV (RFC 2518) que indica que el procesamiento continuará. |
| 200 | La solicitud fue exitosa y los encabezados de respuesta o el cuerpo de datos esperados por la solicitud se devolverán con esta respuesta. |
| 201 | La solicitud se cumplió, se creó un nuevo recurso según las necesidades de 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 Aceptado'. |
| 202 | El servidor aceptó la solicitud pero aún no la procesó. Así como puede ser denegada, la solicitud puede o no ejecutarse en última instancia. En el caso de operaciones asincrónicas, no hay forma más cómoda que enviar este código de estado. El propósito de devolver una respuesta de 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 la operación por lotes. esta completado. Una respuesta que acepta el procesamiento de la solicitud y devuelve un código de estado 202 debe contener alguna información en la entidad devuelta que indique el estado actual del procesamiento, 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 se ha completado. |
| 203 | El servidor procesó con éxito la solicitud, pero la metainformación del encabezado de la entidad devuelta no es un conjunto definido válido 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 puede hacer que el servidor de origen conozca la superinformación sobre los metadatos. El uso de este código de estado no es obligatorio y solo es apropiado si la respuesta hubiera devuelto 200 OK sin este código de estado. |
| 204 | El servidor procesó exitosamente la solicitud pero no necesita devolver ningún contenido de entidad y desea devolver metainformación actualizada. La respuesta puede devolver metainformación nueva o actualizada en forma de encabezados de entidad. Estos encabezados, si están presentes, deben corresponder a las variables solicitadas. Si el cliente es un navegador, el navegador del usuario DEBE conservar la página para la cual se realizó la solicitud sin ningún cambio en la vista del documento, incluso si se debe aplicar metainformación nueva o actualizada a la actividad del navegador del usuario de acuerdo con la especificación Documentos a la vista. Dado que una respuesta 204 tiene prohibido contener cualquier cuerpo de mensaje, siempre termina con la primera línea vacía después del encabezado del mensaje. |
| 205 | El servidor procesó exitosamente la solicitud y no devolvió nada. Pero a diferencia de una respuesta 204, una respuesta que devuelve este código de estado requiere que el solicitante restablezca la vista del documento. Esta respuesta 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 otra entrada. Al igual que la respuesta 204, esta respuesta tiene prohibido contener cualquier cuerpo de mensaje y termina con la primera línea en blanco después del encabezado del mensaje. |
| 206 | El servidor ha procesado con éxito parte de la solicitud GET. Las herramientas de descarga HTTP como FlashGet o Thunder utilizan este tipo de respuesta para reanudar descargas interrumpidas o dividir un documento grande en múltiples segmentos de descarga para una descarga simultánea. La solicitud debe incluir un encabezado Range para indicar el rango de contenido que espera el cliente y puede incluir un If-Range como condición de solicitud. La respuesta debe incluir los siguientes campos de encabezado: Content-Range se utiliza para indicar el rango de contenido devuelto en esta respuesta; si se trata de una descarga de varias partes con Content-Type multipart/byteranges, cada parte de varias partes debe contener Content-Range. dominio se utiliza para indicar el alcance del contenido de este párrafo. Si se incluye Content-Length en la respuesta, su valor debe coincidir con el número real de bytes en el rango de contenido que devuelve. 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 esta solicitud de respuesta utiliza una verificación de caché fuerte de If-Range, entonces esta respuesta no debe contener otros encabezados de entidad; si esta solicitud de respuesta usa una verificación de caché débil de If-Range, entonces esta respuesta tiene prohibido contener otros encabezados de entidad; esto evita Resuelve inconsistencias entre contenido de la entidad almacenado en caché e información actualizada del encabezado de la entidad. De lo contrario, esta respuesta debe contener todos los campos de encabezado de entidad que deben devolverse en una respuesta 200. Si el encabezado ETag o Last-Modified no coincide 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 encabezados Range y Content-Range tiene prohibido almacenar en caché el contenido devuelto por una respuesta 206. |
| 207 | El código de estado extendido por WebDAV (RFC 2518) significa que el cuerpo del mensaje posterior será un mensaje XML y puede contener una serie de códigos de respuesta independientes dependiendo del número de subsolicitudes anteriores. |
| 300 | El recurso solicitado tiene una serie de respuestas opcionales, cada una con su propia dirección específica e información de negociación del controlador del navegador. El usuario o navegador puede elegir una dirección preferida para la redirección. A menos que se trate de una solicitud HEAD, la respuesta debe incluir una entidad con una lista de atributos 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 de la respuesta y las propias capacidades del navegador. Por supuesto, la especificación RFC 2616 no especifica cómo se debe realizar dicha selección automática. Si el servidor ya tiene una opción de comentarios preferida, el URI de estos comentarios debe especificarse en Ubicación; el navegador puede usar este valor de Ubicación como dirección para la redirección automática. Además, esta respuesta se puede almacenar en caché a menos que se especifique lo contrario. |
| 301 | El recurso solicitado se ha movido permanentemente a una nueva ubicación y cualquier referencia futura a este recurso debe utilizar uno de los varios URI devueltos con esta respuesta. Si es posible, los clientes con capacidades de edición de enlaces deben modificar automáticamente la dirección solicitada a la dirección devuelta por el servidor. A menos que se especifique lo contrario, esta respuesta también se puede almacenar en caché. El nuevo URI permanente debe devolverse en el campo Ubicación 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 solicitud GET o HEAD, el navegador prohíbe la redirección automática a menos que el usuario lo confirme, porque las condiciones de la solicitud pueden cambiar en consecuencia. Nota: Para algunos navegadores que utilizan el protocolo HTTP/1.0, cuando la solicitud POST que envían recibe una respuesta 301, la solicitud de redireccionamiento posterior se convertirá en un método GET. |
| 302 | El recurso solicitado ahora responde temporalmente a solicitudes de un URI diferente. Debido a que dichas redirecciones son temporales, el cliente debe continuar enviando solicitudes futuras a la dirección original. Esta respuesta se puede almacenar en caché solo si se especifica en Cache-Control o Expires. El nuevo URI temporal debe devolverse en el campo Ubicación 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 solicitud GET o HEAD, el navegador prohíbe la redirección automática a menos que el usuario lo confirme, porque las condiciones de la solicitud pueden cambiar en consecuencia. Nota: Aunque las especificaciones RFC 1945 y RFC 2068 no permiten que el cliente cambie el método de solicitud al redireccionar, muchos navegadores existentes consideran la respuesta 302 como una respuesta 303 y utilizan el método GET para acceder al URI especificado en la Ubicación, independientemente. del método de la solicitud original. Se agregaron los códigos de estado 303 y 307 para aclarar qué respuesta espera el servidor del cliente. |
| 303 | La respuesta a la solicitud actual se puede encontrar en otro URI y el cliente debe usar GET para acceder a ese recurso. Este método existe principalmente para permitir que la salida de la solicitud POST activada por script se redirija a un nuevo recurso. Este nuevo URI no es una referencia de reemplazo del recurso original. Al mismo tiempo, se prohíbe el almacenamiento en caché de las respuestas 303. Por supuesto, la segunda solicitud (redireccionamiento) podría almacenarse en caché. El nuevo URI debe devolverse en el campo Ubicación 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. Nota: Muchos navegadores anteriores a HTTP/1.1 no comprenden correctamente el estado 303. Si necesita considerar la interacción con estos navegadores, el código de estado 302 debería ser suficiente, porque la mayoría de los navegadores manejan las respuestas 302 exactamente de la misma manera que la especificación anterior requiere que el cliente maneje las respuestas 303. |
| 304 | Si el cliente envía una solicitud GET condicional y la solicitud está 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. Una respuesta 304 tiene prohibido incluir un cuerpo de mensaje, por lo que siempre termina con la primera línea en blanco después del encabezado del mensaje. La respuesta DEBE contener la siguiente información de encabezado: Fecha, a menos que el servidor no tenga reloj. Si los servidores sin relojes también cumplen con estas reglas, entonces los servidores proxy y los clientes pueden agregar el campo Fecha a los encabezados de respuesta recibidos (como se especifica en RFC 2068) y el mecanismo de almacenamiento en caché funcionará normalmente. ETag y/o Content-Location, 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 esta solicitud de respuesta utiliza una verificación de caché sólida, entonces esta respuesta no debe contener otros encabezados de entidad; de lo contrario (por ejemplo, una solicitud GET condicional usa una verificación de caché débil), esta respuesta tiene prohibido contener otros encabezados de entidad; esto evita Resuelve inconsistencias entre los encabezados de entidad contenido de la entidad e información actualizada del encabezado de la entidad. 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 restricción. Si se recibe una respuesta 304 que requiere una actualización de una entrada de caché, el sistema de caché debe actualizar la entrada completa para reflejar los valores de todos los campos que se actualizaron en la respuesta. |
| 305 | Se debe acceder al recurso solicitado a través del proxy especificado. La información URI del proxy especificado se proporcionará en el campo Ubicación. El destinatario debe enviar repetidamente una solicitud por separado para acceder a los recursos correspondientes a través de este proxy. Sólo el servidor de origen puede establecer una respuesta 305. NOTA: RFC 2068 no especifica que una respuesta 305 esté destinada a redirigir una única solicitud y solo puede ser establecida 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 | El recurso solicitado ahora responde temporalmente a solicitudes de un URI diferente. Debido a que dichas redirecciones son temporales, el cliente debe continuar enviando solicitudes futuras a la dirección original. Esta respuesta se puede almacenar en caché solo si se especifica en Cache-Control o Expires. El nuevo URI temporal debe devolverse en el campo Ubicación 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. Debido a que algunos navegadores no pueden reconocer la respuesta 307, es necesario agregar la información necesaria anterior para que los usuarios puedan comprender y realizar solicitudes de acceso al nuevo URI. Si no se trata de una solicitud GET o HEAD, el navegador prohíbe la redirección automática a menos que el usuario lo confirme, porque las condiciones de la solicitud pueden cambiar en consecuencia. |
| 400 | 1. La semántica es incorrecta y el servidor no puede entender la solicitud actual. El cliente no debe volver a enviar esta solicitud a menos que se modifique. 2. Los parámetros de la solicitud son incorrectos. |
| 401 | La solicitud actual requiere autenticación de usuario. La respuesta DEBE incluir un encabezado WWW-Authenticate apropiado para el recurso solicitado que solicita información del usuario. El cliente puede enviar repetidamente una solicitud que contenga la información del encabezado de Autorización adecuada. Si la solicitud actual ya contiene certificados de autorización, la respuesta 401 indica que la verificación del servidor ha rechazado esos certificados. Si la respuesta 401 contiene la misma consulta de autenticación que la respuesta anterior, y el navegador ha intentado la autenticación al menos una vez, el navegador debe mostrar la información de la entidad contenida en la respuesta al usuario, porque esta información de la entidad puede contener información de diagnóstico relevante. Véase RFC 2617. |
| 402 | Este código de estado está reservado para posibles necesidades futuras. |
| 403 | El servidor entendió la solicitud, pero se negó a ejecutarla. A diferencia de una respuesta 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 se puede ejecutar la solicitud, entonces el motivo del rechazo debe describirse 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 solicitud falló. El recurso solicitado no se encontró en el servidor. No hay información que le diga al usuario si la condición es temporal o permanente. Si el servidor conoce la situación, debe usar el código de estado 410 para informar que el recurso anterior no está disponible permanentemente debido a algunos problemas del mecanismo de configuración interno y que no hay una dirección de salto. El código de estado 404 se usa ampliamente cuando el servidor no quiere revelar por qué se rechazó la solicitud o no hay otra respuesta adecuada disponible. |
| 405 | 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 una información de encabezado Permitir para indicar la lista de métodos de solicitud que el recurso actual puede aceptar. Dado que los métodos PUT y DELETE escribirán recursos en el servidor, la mayoría de los servidores web no admiten o no permiten los métodos de solicitud anteriores en la configuración predeterminada, y se devolverá un error 405 para dichas solicitudes. |
| 406 | Las características de contenido del recurso solicitado no satisfacen las condiciones del encabezado de la solicitud, por lo que no se puede generar la entidad de respuesta. A menos que se trate de una solicitud HEAD, la respuesta debe devolver una entidad que contenga una lista de atributos y direcciones de entidades entre las que el usuario o el navegador pueda elegir la más adecuada. El formato de la entidad está determinado por el tipo de medio definido en el encabezado Tipo de contenido. El navegador puede hacer su mejor elección según el formato y sus capacidades. Sin embargo, la especificación no define ningún criterio para realizar dichas selecciones automáticas. |
| 407 | Similar a una respuesta 401, excepto que el cliente debe autenticarse con el servidor proxy. El servidor proxy debe devolver un Proxy-Authenticate para la consulta de identidad. El cliente puede devolver un encabezado Proxy-Authorization para su verificación. Véase RFC 2617. |
| 408 | Tiempo de espera agotado. El cliente no completó el envío de una solicitud dentro del tiempo que el servidor estaba preparado para esperar. El cliente puede volver a enviar esta solicitud en cualquier momento sin realizar ningún cambio. |
| 409 | La solicitud no se puede completar debido a un conflicto con el estado actual del recurso solicitado. Este código solo debe usarse si se cree que el usuario puede resolver el conflicto y volver a enviar una nueva solicitud. La respuesta debe contener suficiente información para que el usuario descubra el origen del conflicto. Los conflictos suelen ocurrir en el procesamiento de solicitudes PUT. Por ejemplo, en un entorno que utiliza la verificación de versiones, si la información de la versión adjunta a una solicitud de modificación para un recurso específico enviada por un PUT entra en conflicto con una solicitud anterior (de terceros), entonces el servidor debería devolver un error 409 en este momento. Informar al usuario que la solicitud no se puede completar. En este momento, es probable que la entidad de respuesta contenga una comparación de diferencias entre las dos versiones en conflicto, de modo que el usuario pueda volver a enviar la nueva versión después de la fusión. |
| 410 | El recurso solicitado ya no está disponible en el servidor y no tiene ninguna dirección de reenvío conocida. Esta situación debería 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 el código de estado 404. A menos que se indique lo contrario, esta respuesta se puede almacenar en caché. El propósito de la respuesta 410 es principalmente 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 espera que todas las conexiones remotas que apunten a este recurso también se eliminen. Este tipo de incidente es común entre los servicios de valor agregado por tiempo limitado. De manera similar, la respuesta 410 también se utiliza para notificar al cliente que los recursos que originalmente pertenecían a un individuo ya no están disponibles en el sitio del servidor actual. 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 mantener esta marca. |
| 411 | El servidor se niega a aceptar la solicitud sin el encabezado Content-Length definido. Después de agregar un encabezado Content-Length válido que indique la longitud del cuerpo del mensaje de solicitud, el cliente puede enviar la solicitud nuevamente. |
| 412 | El servidor no cumplió con uno o más de los requisitos previos indicados en los campos del encabezado de la solicitud al validarlos. 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 recuperar el recurso, evitando así que el método de solicitud se aplique al recurso de forma distinta a la esperada. |
| 413 | El servidor se niega a procesar la solicitud actual porque la solicitud envió datos de entidad que son más grandes de lo 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 continúe enviando esta solicitud. Si la situación es temporal, el servidor debe devolver un encabezado de respuesta Retry-After para informar al cliente durante cuánto tiempo puede volver a intentarlo. |
| 414 | 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. Esto es relativamente raro. Las situaciones comunes incluyen: el envío de un formulario que debería usar el método POST se convierte en el método GET, lo que hace que la cadena de consulta (Query String) sea demasiado larga. Redireccionamiento de URI "agujero negro", por ejemplo, cada redireccionamiento utiliza el URI antiguo como parte del nuevo URI, lo que hace que el URI sea demasiado largo después de varias redirecciones. El cliente intenta atacar el servidor explotando una vulnerabilidad de seguridad que existe en algunos servidores. Este tipo de servidor utiliza un búfer de longitud fija para leer u operar el URI solicitado. Cuando los parámetros después de GET exceden un cierto valor, puede ocurrir un desbordamiento del búfer, lo que provoca la ejecución de código arbitrario [1]. Los servidores sin tales vulnerabilidades deberían devolver un código de estado 414. |
| 415 | 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, por lo que la solicitud se rechaza. |
| 416 | Si la solicitud contiene el encabezado de solicitud 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 estado 416 código. Si Range usa un rango de bytes, entonces esta situación significa que la posición del primer byte 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 para indicar la longitud del recurso actual mientras devuelve el código de estado 416. Esta respuesta también tiene prohibido utilizar rangos multiparte/bytes como tipo de contenido. |
| 417 | El servidor no puede satisfacer el contenido esperado especificado en el encabezado de la solicitud Expect, o el servidor es un servidor proxy y tiene evidencia clara de que el contenido de Expect no puede satisfacerse en el siguiente nodo de la ruta actual. |
| 421 | La cantidad de conexiones al servidor desde la dirección IP del cliente actual excede el rango máximo permitido del servidor. Por lo general, la dirección IP aquí se refiere a 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 recuento de conexiones puede involucrar a más de un usuario final. |
| 422 | La cantidad de conexiones al servidor desde la dirección IP del cliente actual excede el rango máximo permitido del servidor. Por lo general, la dirección IP aquí se refiere a 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 recuento de conexiones puede involucrar a más de un usuario final. |
| 422 | La solicitud está bien formateada, pero no se puede responder debido a errores semánticos. (RFC 4918 WebDAV) 423 BloqueadoEl recurso actual está bloqueado. (RFC 4918 WebDAV) |
| 424 | La solicitud actual falló debido a un error en una solicitud anterior, como PROPPATCH. (RFC 4918 WebDAV) |
| 425 | Definido en el borrador de Colecciones avanzadas de WebDav, pero no aparece en el "Protocolo de recopilación de secuencias WebDAV" (RFC 3658). |
| 426 | Los clientes deben cambiar a TLS/1.0. (RFC 2817) |
| 449 | Ampliado por Microsoft, indica que las solicitudes deben volver a intentarse después de realizar las acciones adecuadas. |
| 500 | El servidor encontró una condición inesperada que le impidió completar el procesamiento de la solicitud. En términos generales, este problema ocurrirá 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 solicitud de ningún recurso. |
| 502 | Un servidor que funciona como puerta de enlace o proxy recibió una respuesta no válida de un servidor ascendente mientras intentaba realizar una solicitud. |
| 503 | Debido al mantenimiento temporal del servidor o a la sobrecarga, el servidor actualmente no puede procesar solicitudes. Esta condición es temporal y se restablecerá después de un período de tiempo. Si se puede esperar el tiempo de retraso, la respuesta puede incluir un encabezado Retry-After para indicar el tiempo de retraso. Si no se proporciona este mensaje Reintentar después, el cliente DEBE manejarlo de la misma manera que maneja una respuesta 500. Nota: La presencia del código de estado 503 no significa que el servidor deba usarlo cuando está sobrecargado. Algunos servidores simplemente desean denegar las conexiones de los clientes. |
| 504 | Cuando un servidor que funciona como puerta de enlace o proxy intenta ejecutar una solicitud, no recibe una respuesta oportuna del servidor ascendente (el servidor identificado por el URI, como HTTP, FTP, LDAP) o del servidor auxiliar (como DNS). ). Nota: Algunos servidores proxy devolverán un error 400 o 500 cuando se agote el tiempo de espera de la consulta DNS. |
| 505 | El servidor no admite, o se niega a admitir, la versión 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), indica que el servidor tiene un error de configuración interno: el recurso de argumento de negociación solicitado está configurado para usarse en la negociación de contenido transparente y, por lo tanto, no es un enfoque apropiado en un proceso de 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 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 | Las estrategias requeridas para obtener recursos aún no están satisfechas. (RFC 2774) |