| Código 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 del mensaje Upgrade que utilice un protocolo diferente para completar la petición. Después de enviar la última línea en blanco de esta respuesta, el servidor cambiará a los protocolos definidos en la cabecera del mensaje Upgrade. Esto sólo debe hacerse si es más beneficioso cambiar a un nuevo protocolo. Por ejemplo, cambiar a una nueva versión de HTTP es más ventajoso que a una versión anterior, o cambiar a un protocolo síncrono y en tiempo real para entregar recursos que aprovechen tales características. |
| 102 | Los códigos de estado, ampliados por WebDAV (RFC 2518), representan que el procesamiento continuará. |
| 200 | La solicitud se ha realizado correctamente y la cabecera de respuesta o el cuerpo de datos deseados por la solicitud se devolverán con esta respuesta. |
| 201 | La solicitud se ha cumplido y se ha creado un nuevo recurso según lo requerido por la solicitud y su URI se ha devuelto con la cabecera Location. Si el recurso solicitado no puede crearse a tiempo, se devolverá '202 Accepted'. |
| 202 | El servidor ha aceptado la petición, pero aún no la ha procesado. Al igual que puede ser rechazada, eventualmente la petición puede o no ser ejecutada. En el contexto de las operaciones asíncronas, no hay nada más conveniente que enviar este código de estado. El propósito de devolver una respuesta con un código de estado 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 tener que mantener al cliente conectado al servidor hasta que la operación por lotes se haya completado por completo. Una respuesta que acepta una solicitud de procesamiento y devuelve un código de estado 202 DEBERÍA 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 se ha completado. |
| 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 versión original. Por ejemplo, los metadatos que contienen recursos pueden hacer que el servidor original 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 meta-información actualizada. La respuesta puede devolver meta-información nueva o actualizada en forma de cabeceras de entidad. Si existen tales cabeceras, deben corresponder a las variables solicitadas. Si el cliente es un navegador, entonces 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 según la especificación la meta-información nueva o actualizada DEBERÍA 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 ha procesado correctamente la solicitud y no ha devuelto 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 documento de gran tamaño en varios segmentos de descarga al mismo tiempo. La petición 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 petición. La respuesta debe contener los siguientes campos de cabecera: Content-Range para indicar el alcance del contenido devuelto en esta respuesta; en el caso de una descarga de varios segmentos con un Content-Type de multipart/byteranges, cada segmento multiparte debe contener un campo Content-Range que indique 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. 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 ser diferentes de otras respuestas con las mismas variables. Expires, Cache-Control, y/o Vary, si sus valores pueden ser diferentes de los valores de otras respuestas anteriores para las mismas variables. Esta respuesta NO DEBERÍA contener otras cabeceras de entidad si la petición utiliza validación de caché fuerte If-Range, y NO DEBERÍA contener otras cabeceras de entidad si la petición utiliza validación de caché débil If-Range; esto evita inconsistencias entre el contenido de entidad en caché y la información de cabecera de entidad actualizada. De lo contrario, esta respuesta DEBERÍA contener todos los campos de cabecera de entidad que deberían haber sido devueltos en todas las respuestas 200 que deberían haber sido devueltas. Si las cabeceras ETag o Last-Modified no coinciden exactamente, la caché del lado del cliente DEBERÍA prohibir 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 | El código de estado, ampliado 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, en función del número de subpeticiones anteriores. |
| 300 | El recurso solicitado tiene una serie de mensajes de retorno alternativos, cada uno con su propia dirección específica e información de negociación basada en el navegador. El usuario o el navegador pueden seleccionar por sí mismos 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 tal elección automática. Si el propio servidor ya tiene una elección preferida de respuesta, entonces el URI de esta respuesta debe especificarse en Location; el navegador puede usar este valor de Location como la dirección para la redirección automática. Además, esta respuesta también 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, el navegador tiene prohibido 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á una 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 continuar 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 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 en 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 alternativa al recurso original. Además, está prohibido almacenar en caché la respuesta 303. Por supuesto, la segunda petición (redirección) puede almacenarse en caché. El nuevo URI 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. Nota: Muchos navegadores anteriores a las versiones 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 ser suficiente, ya que la mayoría de los navegadores procesan las respuestas 302 exactamente de la misma manera que la especificación anterior requiere que el cliente lo haga al procesar una respuesta 303. |
| 304 | El servidor DEBERÍA devolver este código de estado si el cliente envía una petición GET condicional que ha sido permitida y el contenido del documento (desde la última visita o según las condiciones de la petición) no ha cambiado.Las respuestas 304 tienen prohibido contener 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 las siguientes cabeceras: 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 hubiera devuelto una respuesta 200.Expires Expires, Cache-Control, y/o Vary, si el valor puede ser diferente del correspondiente a otras respuestas anteriores para la misma variable. Si esta solicitud de respuesta utiliza una validación de caché fuerte, esta respuesta no debe contener otras cabeceras de entidad; en caso contrario (por ejemplo, una solicitud GET condicional utiliza una validación de caché débil), se prohíbe que esta respuesta contenga otras cabeceras de entidad; 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 del proxy especificado. el campo Ubicación proporcionará información sobre el URI en el que se encuentra el proxy especificado. el destinatario deberá enviar repetidamente otra solicitud 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 original. Ignorar estas restricciones podría 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 responde ahora temporalmente a la petición desde un URI diferente. Dado que estas redirecciones son temporales, 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, a menos que el usuario lo confirme, porque las condiciones de la solicitud pueden cambiar. |
| 400 | 1. Hay un error semántico y la petición actual no puede ser entendida por el servidor. A menos que se modifique, el cliente no debe enviar repetidamente esta solicitud. 2. Los parámetros de la solicitud son erróneos. |
| 401 | La solicitud actual requiere autenticación de usuario. La respuesta debe contener una cabecera WWW-Authenticate para el recurso solicitado para pedir información del usuario. El cliente puede enviar repetidamente una solicitud que contenga la información apropiada de la cabecera de Autorización. Si la solicitud actual ya contiene credenciales de Autorización, la respuesta 401 significa que el servidor verifica que dichas credenciales han sido rechazadas. Si la respuesta 401 contiene la misma consulta de autenticación que la respuesta anterior, y el navegador ya ha intentado la autenticación al menos una vez, entonces el navegador DEBERÍA presentar 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 esta petición no debería ser reenviada. Si no se trata de una petición HEAD y el servidor quiere ser capaz de hablar claramente sobre por qué la petición no puede ser ejecutada, entonces la razón de la denegación debe ser descrita dentro de la entidad. Por supuesto, el servidor también puede devolver una respuesta 404 si no desea dar ninguna información al cliente. |
| 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 usuario 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 petición 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 soportan estos métodos de petición o no los permiten por defecto, y devolverán un error 405 para tales peticiones. |
| 406 | Las características de 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 una lista de características y direcciones de entidad entre las que el usuario o el navegador puedan seleccionar la más apropiada. El formato de la entidad viene determinado por el tipo de medio definido en la cabecera Content-Type. Los navegadores pueden hacer sus propias elecciones 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 en que el cliente DEBE autenticarse en el servidor proxy. El servidor proxy DEBE devolver un Proxy-Authenticate para la interrogación de identidad. El cliente PUEDE devolver una cabecera Proxy-Authorization para autenticación. Véase RFC 2617. |
| 408 | Request timeout. El cliente no completó el envío de una petición dentro del tiempo que el servidor estaba preparado para esperar. El cliente PUEDE volver a enviar la petición 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 suelen producirse en el procesamiento de solicitudes PUT. Por ejemplo, en un entorno de comprobación de versiones, si la información de versión adjunta a una solicitud PUT enviada para modificar un recurso concreto entra en conflicto con una solicitud anterior (de terceros), el servidor debe devolver un error 409 informando al usuario de que la solicitud no se ha podido completar. 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 tras 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 condición debe considerarse permanente. Si es posible, los clientes con capacidades de edición de enlaces deben eliminar todas las referencias a esta dirección con el permiso del usuario. Si el servidor no sabe o no puede determinar si esta condición es permanente, entonces se debe utilizar un código de estado 404. A menos que se indique lo contrario, esta respuesta es almacenable en caché.410 El propósito de la respuesta es principalmente ayudar al webmaster en el mantenimiento del sitio informando al usuario de que el recurso ya no está disponible y que el propietario del servidor desea que todas las conexiones remotas a este 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 a los clientes que un recurso que originalmente pertenecía a un individuo en el sitio del servidor actual ya no está disponible. Por supuesto, es decisión del propietario del servidor si todos los recursos no disponibles permanentemente deben marcarse como "410 Gone" y cuánto tiempo debe mantenerse esta marca. |
| 411 | El servidor se niega a aceptar peticiones sin la cabecera Content-Length definida. Tras añadir una cabecera Content-Length válida que indique la longitud del cuerpo del mensaje de solicitud, el cliente puede volver a enviar la solicitud. |
| 412 | El servidor no ha podido satisfacer uno o más de los requisitos previos al comprobar que se indicaban en el campo de cabecera de la solicitud. Este código de estado permite al cliente establecer condiciones previas en el metamensaje 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 datos de entidad de un tamaño superior al 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 esta condición es temporal, el servidor debe devolver una cabecera de respuesta Retry-After para informar al cliente de cuánto tiempo puede reintentar después. |
| 414 | La longitud del URI de la petición excede la longitud que el servidor puede interpretar, por lo que el servidor rechaza 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 antiguo URI como parte del nuevo URI con 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 de una petición, y cuando los parámetros tras un GET superan un determinado valor, puede producirse un desbordamiento del búfer, lo que lleva 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 en el servidor, por lo que 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 se solapa con los rangos disponibles para el recurso actual, y la cabecera de petición If-Range no está definida en la petición, entonces el servidor debería devolver un código de estado 416. Si Range utiliza rangos de bytes, entonces este es el caso si la primera posición de bytes de todos los rangos de datos especificados en la petición excede 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 este 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 donde se encuentra el cliente actual excede el máximo permitido por el servidor. Típicamente, la dirección IP aquí se refiere a la dirección del cliente vista desde el servidor (por ejemplo, la puerta de enlace del usuario o la dirección del servidor proxy). En este caso, el recuento de conexiones puede implicar a más de un usuario final. |
| 422 | El número de conexiones al servidor desde la dirección IP del cliente actual excede el máximo permitido por el servidor. Típicamente, la dirección IP aquí se refiere a la dirección del cliente vista desde el servidor (por ejemplo, la puerta de enlace del usuario o la dirección del servidor proxy). En este caso, el recuento de conexiones puede implicar a más de un usuario final. |
| 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) |
| 424 | La solicitud actual falló debido a un error que ocurrió 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 se encontró con una situació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 concreta necesaria para la solicitud actual. Cuando el servidor es incapaz de reconocer el método solicitado y no es capaz de 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 desean denegar la conexión al cliente. |
| 504 | Un servidor que funciona como pasarela o proxy y que intenta realizar una petición no recibe una respuesta a tiempo 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 ampliamente utilizado. |
| 510 | La política requerida para obtener el recurso no fue incumplida. (RFC 2774) |