| Código de Estado HTTP |
Significado del Código |
| 100 |
El cliente debe continuar enviando la solicitud. Esta respuesta temporal se utiliza para notificar 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 si la solicitud ya se completó, ignorar esta respuesta. El servidor debe enviar una respuesta final al cliente una vez que se complete la solicitud. |
| 101 |
El servidor ha comprendido la solicitud del cliente y notificará al cliente mediante el encabezado de mensaje Upgrade que debe utilizar un protocolo diferente para completar esta solicitud. Después de enviar esta respuesta, el servidor cambiará a los protocolos definidos en el encabezado Upgrade. Las medidas similares deben tomarse sólo cuando los beneficios de cambiar a un nuevo protocolo sean claros, por ejemplo, al cambiar a una nueva versión de HTTP que es más ventajosa que la versión antigua, o al cambiar a un protocolo en tiempo real y sincronizado para transmitir recursos que se beneficien de tales características. |
| 102 |
Código de estado extendido por WebDAV (RFC 2518), que indica que el procesamiento continuará. |
| 200 |
La solicitud fue exitosa; los encabezados o el cuerpo de respuesta deseados se devolverán con esta respuesta. |
| 201 |
La solicitud ha sido cumplida y se ha creado un nuevo recurso basado en los requisitos de la solicitud, y su URI ha sido devuelto con la cabecera Location. Si no se puede crear el recurso requerido de inmediato, se debe regresar '202 Accepted'. |
| 202 |
El servidor ha aceptado la solicitud, pero aún no se ha procesado. Como puede haber sido rechazada, la solicitud puede o no ser ejecutada al final. En el caso de operaciones asíncronas, no hay una mejor práctica que retornar este código de estado. La respuesta que tiene el código 202 tiene como propósito permitir que el servidor acepte solicitudes de otros procesos (como un proceso por lotes que se ejecuta una vez al día) sin que el cliente tenga que mantener constantemente la conexión con el servidor hasta que se complete toda la operación por lotes. La respuesta que acepta la solicitud de procesamiento y retorna el código 202 debe incluir en el cuerpo una indicación del estado actual del procesamiento y un puntero a los monitores del estado del procesamiento o de previsión del 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 información del encabezado del cuerpo de respuesta no es un conjunto de datos válidos en el servidor original, sino una copia local o de terceros. La información actual puede ser un subconjunto o superconjunto de la versión original. Por ejemplo, los metadatos que contienen el recurso podrían llevar al servidor original a conocer una metainformación que contenga más detalles. No es necesario usar este código de estado, y solo es apropiado si la respuesta, sin usar este código de estado, devolvería 200 OK. |
| 204 |
El servidor ha procesado con éxito la solicitud, pero no se debe devolver ningún contenido del cuerpo y desea devolver metainformación actualizada. La respuesta puede regresar nueva o actualizada metainformación a través de encabezados del cuerpo. Si hay información de encabezado, debe corresponder a las variables solicitadas. Si el cliente es un navegador, entonces el navegador del usuario debe mantener el documento que envió la solicitud sin cambiar la vista del documento, incluso cuando, según la especificación, la nueva o actualizada metainformación debe ser aplicada a la vista activa del documento en el navegador del usuario. Dado que una respuesta 204 tiene prohibido incluir cualquier cuerpo de mensaje, siempre termina con un primer salto de línea después de los encabezados de mensaje. |
| 205 |
El servidor ha procesado con éxito la solicitud y no ha devuelto ningún contenido. Sin embargo, a diferencia de la respuesta 204, la respuesta que devuelve este código de estado requiere que el solicitante restablezca la vista del documento. Esta respuesta se utiliza principalmente para restablecer los formularios inmediatamente después de aceptar la entrada del usuario, para que el usuario pueda comenzar a ingresar de nuevo fácilmente. Al igual que la respuesta 204, esta respuesta también tiene prohibido incluir cualquier cuerpo de mensaje y termina con un primer salto de línea después de los encabezados de mensaje. |
| 206 |
El servidor ha procesado con éxito parte de una solicitud GET. Utilidades de descarga HTTP como FlashGet o Thunder utilizan este tipo de respuesta para implementar la reanudación de descargas o dividir un documento grande en múltiples segmentos de descarga simultáneamente. La solicitud debe incluir un encabezado Range para indicar el rango de contenido que desea recibir del cliente, y puede incluir If-Range como condición de solicitud. La respuesta debe incluir los siguientes campos de encabezado: Content-Range para indicar el rango de contenido devuelto en esta respuesta; si el Content-Type es multipart/byteranges de descargas múltiples, cada segmento multipart debe incluir un campo Content-Range para indicar el rango de contenido de ese segmento. Si la respuesta incluye Content-Length, su valor debe coincidir con el número real de bytes en el rango de contenido devuelto. Date ETag y/o Content-Location, si la misma solicitud hubiera debido devolver una respuesta 200. Expires, Cache-Control y/o Vary, si sus valores pueden diferir de otros valores correspondientes a la variable anterior. Si la solicitud de esta respuesta utiliza la validación de caché fuerte If-Range, entonces esta respuesta no debe incluir otros encabezados de entidad; si la solicitud de esta respuesta utiliza la validación de caché débil If-Range, entonces esta respuesta prohíbe incluir otros encabezados de entidad; esto evita una inconsistencia entre el contenido de entidad en caché y la información de encabezado de entidad actualizada. Por otro lado, esta respuesta debe contener todos los campos de encabezado de entidad que deberían haber sido devueltos en una respuesta 200. Si los encabezados ETag o Last-Modified no coinciden con precisión, el caché del cliente no debería combinar el contenido devuelto en la respuesta 206 con ningún contenido previamente almacenado en caché. |
| 207 |
Código de estado extendido por WebDAV (RFC 2518), que indica que el cuerpo del mensaje subsecuente será un mensaje XML y puede contener una serie de códigos de respuesta individuales dependiendo de la cantidad de solicitudes secundarias anteriores. |
| 300 |
El recurso solicitado tiene una gama de información de respuesta que está disponible, cada una con su propia dirección específica y mensaje de marketing impulsado por el navegador. El usuario o navegador pueden escoger una dirección preferida para la redirección. A menos que se trate de una solicitud HEAD, esta respuesta debe incluir un cuerpo de entidad que liste las características de los recursos y las direcciones, para que el usuario o navegador pueda elegir la dirección de redirección más adecuada. El formato de este cuerpo es determinado por el formato definido en el encabezado Content-Type. El navegador puede tomar una decisión automáticamente sobre la selección más adecuada, dependiendo del formato de respuesta y de la capacidad del navegador. Sin embargo, la norma RFC 2616 no especifica cómo se realiza tal selección automática. Si el servidor ya tiene una opción de respuesta preferida, debe indicar la URI de esta respuesta en el campo Location; el navegador puede tomar este valor de Location como la dirección de redirección automática. Además, a menos que se especifique lo contrario, esta respuesta también es cacheable. |
| 301 |
El recurso solicitado se ha movido de forma permanente a una nueva ubicación, y cualquier referencia futura a este recurso debe utilizar uno de los URIs devueltos por esta respuesta. Siempre que sea posible, los clientes que tienen la capacidad de editar enlaces deben modificar automáticamente la dirección solicitada a la dirección devuelta por el servidor. A menos que se indique lo contrario, esta respuesta también es cacheable. El nuevo URI permanente debe ser devuelto en el campo Location de la respuesta. A menos que se trate de una solicitud HEAD, el cuerpo de la respuesta debe incluir un hiperenlace a la nueva URI y una breve descripción. Si esto no es una solicitud GET o HEAD, el navegador prohíbe la redirección automática a menos que se obtenga la confirmación del usuario, ya que las condiciones de la solicitud pueden cambiar por esta razón. Nota: Para algunos navegadores que utilizan el protocolo HTTP/1.0, si envían una solicitud POST y reciben una respuesta 301, la siguiente solicitud de redirección se realizará como una solicitud GET. |
| 302 |
El recurso solicitado ahora responde a la solicitud desde un URI diferente de forma temporal. Debido a que esta redirección es temporal, el cliente debe continuar enviando solicitudes futuros a la dirección original. Esta respuesta solo es cacheable si está específicamente indicado en Cache-Control o Expires. El nuevo URI temporal debe ser devuelto en el campo Location de la respuesta. A menos que se trate de una solicitud HEAD, el cuerpo de la respuesta debe incluir un hiperenlace a la nueva URI y una breve descripción. Si esto no es una solicitud GET o HEAD, el navegador prohíbe automáticamente la redirección a menos que se obtenga la confirmación del usuario, dado que las condiciones de la solicitud pueden cambiar por esa razón. Nota: Aunque la norma RFC 1945 y RFC 2068 no permiten que un cliente cambie el método de solicitud en la redirección, muchos navegadores existentes tratan una respuesta 302 como una respuesta 303, utilizando el método GET para acceder al URI especificado en Location, ignorando el método original de la solicitud. Los códigos de estado 303 y 307 se añadieron para aclarar qué tipo de respuesta debe esperar el cliente. |
| 303 |
La respuesta correspondiente a la solicitud actual puede ser encontrada en otro URI, y el cliente debe acceder ese recurso utilizando el método GET. La existencia de este método es principalmente para permitir que la salida de solicitudes POST activadas por script se redirija a un nuevo recurso. Este nuevo URI no es una referencia alternativa al recurso original. Además, la respuesta 303 no debe ser almacenada en caché. Sin embargo, la segunda solicitud (de redirección) puede ser almacenada en caché. El nuevo URI debe ser devuelto en el campo Location de la respuesta. A menos que se trate de una solicitud HEAD, el cuerpo de la respuesta debe incluir un hiperenlace a la nueva URI y una breve descripción. Nota: Muchos navegadores anteriores a la versión HTTP/1.1 no entienden correctamente el estado 303. Si debe tener en cuenta la interacción con esos navegadores, el código de estado 302 debería ser suficiente, porque la mayoría de los navegadores manejan el estado 302 de la misma manera que se establece en la norma que el cliente debería manejar el estado 303. |
| 304 |
Si el cliente envía una solicitud GET condicional y esa solicitud ha sido permitida, y el contenido del documento (desde el último acceso o de acuerdo con las condiciones de la solicitud) no ha cambiado, el servidor debe devolver este código de estado. La respuesta 304 prohíbe incluir un cuerpo de mensaje, por lo que siempre termina con el primer salto de línea después de los encabezados de mensaje. Esta respuesta debe incluir la siguiente información de encabezado: Date, a menos que el servidor no tenga reloj. Si un servidor sin reloj también sigue estas reglas, entonces el servidor proxy y el cliente pueden agregar el campo Date a los encabezados de respuesta que reciben (como se establece en el RFC 2068), y el mecanismo de 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 sus valores pueden diferir de otros valores correspondientes a la variable anterior. Si la solicitud de esta respuesta utiliza la validación de caché fuerte, entonces esta respuesta no debe incluir otros encabezados de entidad; de lo contrario (por ejemplo, si una solicitud GET condicional utiliza la validación de caché débil), esta respuesta prohíbe incluir otros encabezados de entidad; esto evita la inconsistencia entre el contenido de entidad en caché y la información de encabezado de entidad actualizada. Si una respuesta 304 indica que se ha determinado que cierta entidad no está almacenada en caché, entonces el sistema de caché debe ignorar esta respuesta y repetir la solicitud sin condiciones. Si se recibe una respuesta 304 que solicita la actualización de un elemento en caché, el sistema de caché debe actualizar todo el elemento para reflejar todos los valores de campo que se hayan actualizado en la respuesta. |
| 305 |
El recurso solicitado debe ser accedido a través del proxy especificado. La información de la URI del proxy especificado se dará en el campo Location, y el destinatario deberá volver a enviar una solicitud separada a través de ese proxy para poder acceder al recurso correspondiente. Solo el servidor original puede establecer una respuesta 305. Nota: El RFC 2068 no establece explícitamente que la respuesta 305 implica redirigir una sola solicitud, y solo puede ser establecida por el servidor original. Ignorar estas restricciones puede tener graves consecuencias de seguridad. |
| 306 |
En la versión más reciente de la especificación, el código de estado 306 ya no se utiliza. |
| 307 |
El recurso solicitado ahora responde a la solicitud desde un URI diferente de forma temporal. Debido a que esta redirección es temporal, el cliente debe continuar enviando solicitudes futuras a la dirección original. Esta respuesta solo es cacheable si está específicamente indicado en Cache-Control o Expires. El nuevo URI temporal debe ser devuelto en el campo Location de la respuesta. A menos que se trate de una solicitud HEAD, el cuerpo de la respuesta debe incluir un hiperenlace a la nueva URI y una breve descripción. Debido a que algunos navegadores no reconocen la respuesta 307, es necesario incluir la información mencionada para que el usuario pueda entender y realizar una solicitud de acceso a la nueva URI. Si esto no es una solicitud GET o HEAD, el navegador prohíbe automáticamente la redirección a menos que se obtenga la confirmación del usuario, ya que las condiciones de la solicitud pueden cambiar por esa razón. |
| 400 |
1. Semántica incorrecta, la solicitud actual no puede ser entendida por el servidor. El cliente no debe volver a enviar esta solicitud a menos que se realicen cambios. 2. Parámetros de solicitud incorrectos. |
| 401 |
La solicitud actual requiere autenticación del usuario. La respuesta debe incluir un encabezado de información WWW-Authenticate correspondiente al recurso solicitado para solicitar la información del usuario. El cliente puede volver a enviar una solicitud que incluya el encabezado de autorización adecuado. Si la solicitud actual ya incluye certificados de autorización, la respuesta 401 indica que el servidor ha rechazado los certificados. Si la respuesta 401 contiene la misma solicitud de autenticación que la respuesta anterior y el navegador ha intentado la autenticación al menos una vez, entonces el navegador debe presentar la información de entidad contenida en la respuesta ya que esta información de entidad puede contener información diagnóstica relevante. Véase RFC 2617. |
| 402 |
Este código de estado se reserva para posibles necesidades futuras. |
| 403 |
El servidor ha comprendido la solicitud, pero se niega a ejecutarla. A diferencia de la respuesta 401, la autenticación no ayudará y esta solicitud no debe volver a ser enviada. Si esto no es una solicitud HEAD y el servidor quiere explicar por qué no se puede ejecutar la solicitud, debe describir la razón del rechazo dentro de la entidad. Por supuesto, el servidor también puede devolver un 404 si no desea que el cliente reciba información. |
| 404 |
La solicitud ha fallado, el recurso que se esperaba no se ha encontrado en el servidor. No hay información que informe al usuario si esta situación es temporal o permanente. Si el servidor conoce la situación, debe utilizar el código de estado 410 para informar que el recurso antiguo ya no está disponible de forma permanente debido a algún problema de configuración interna, y no hay dirección a la que redirigir. Este código de estado 404 se utiliza ampliamente cuando el servidor no quiere revelar por qué la solicitud fue rechazada o no tiene 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. Esta respuesta debe devolver un encabezado Allow para indicar la lista de métodos de solicitud que se pueden aceptar para el recurso actual. Dado que los métodos PUT y DELETE realizarán operaciones de escritura en los recursos en el servidor, la mayoría de los servidores web no los permiten o no los permiten en la configuración predeterminada, por lo que devolverán un error 405 para tales solicitudes. |
| 406 |
Las características del contenido del recurso solicitado no pueden satisfacer las condiciones en los encabezados de solicitud y, por lo tanto, no se puede generar una entidad de respuesta. A menos que sea una solicitud HEAD, esta respuesta debe retornar un cuerpo de entidad que contenga una lista de las características de entidad y dirección que permitirían al usuario o navegador seleccionar la entidad más adecuada. El formato de la entidad es determinado por el tipo de medio definido en el encabezado Content-Type. El navegador puede tomar la mejor decisión basada en el formato y su capacidad. Sin embargo, la norma no define ningún estándar para realizar tales selecciones automáticas. |
| 407 |
Similar a 401, excepto que el cliente debe ser autenticado por el servidor proxy. El servidor proxy debe devolver un encabezado Proxy-Authenticate para solicitar la autenticación. El cliente puede enviar una cabecera Proxy-Authorization para la verificación. Véase RFC 2617. |
| 408 |
La solicitud ha expirado. El cliente no ha completado el envío de una solicitud dentro del tiempo que el servidor estaba preparado para esperar. El cliente puede enviar esta solicitud nuevamente en cualquier momento sin realizar cambios. |
| 409 |
Debido a un conflicto con el estado actual del recurso solicitado, la solicitud no puede completarse. Este código solo puede ser utilizado en tales casos al que el usuario se considera capaz de resolver el conflicto y volver a presentar una nueva solicitud. Esta respuesta debe contener suficiente información para que el usuario descubra la fuente del conflicto. Los conflictos suelen ocurrir en el procesamiento de solicitudes PUT. Por ejemplo, en un entorno donde se hace un control de versiones, si la solicitud de modificación de un recurso específico pertenece a un solicitud PUT que adjunta información de versión que entra en conflicto con una solicitud anterior (de un tercero), entonces el servidor debería devolver un error 409 y notificar al usuario que la solicitud no puede completarse. En este caso, el cuerpo de la respuesta muy probablemente contendría una comparación de las diferencias entre las dos versiones en conflicto para que el usuario vuelva a presentar una nueva versión después de implementar la fusión. |
| 410 |
El recurso solicitado ya no está disponible en el servidor y no hay ninguna dirección de redirección conocida. Esta situación debe considerarse permanente. Siempre que sea posible, los clientes que tengan la capacidad de editar enlaces deben eliminar todas las referencias a esta dirección después de obtener el permiso del usuario. Si el servidor no sabe o no puede determinar si esta situación es permanente, debe utilizar el código de estado 404. A menos que se indique lo contrario, esta respuesta es cacheable. El propósito de la respuesta 410 es principalmente ayudar a los administradores de sitios a mantener sus sitios, notificar a los usuarios de que el recurso ya no está disponible, y que el propietario del servidor desea que todas las conexiones remotas que apuntan a este recurso sean eliminadas. Este tipo de evento es muy común en transacciones y servicios de valor agregado. De igual manera, la respuesta 410 también se utiliza para notificar a los clientes que en el sitio actual del servidor, los recursos que pertenecían originalmente a un individuo ya no están disponibles. Por supuesto, si es necesario marcar todos los recursos que ya no estén disponibles de forma permanente como '410 Gone', y por cuánto tiempo se debe mantener esta marca, depende totalmente del propietario del servidor. |
| 411 |
El servidor se niega a aceptar la solicitud sin un encabezado Content-Length definido. Después de agregar un encabezado Content-Length válido que indique la longitud del cuerpo del mensaje de la solicitud, el cliente puede volver a enviar esa solicitud. |
| 412 |
El servidor no ha podido cumplir uno o más de los pre-requisitos especificados en el campo de encabezado de la solicitud. Este código de estado permite que el cliente establezca pre-requisitos en la metainformación de la solicitud (los datos de los campos de encabezado de la solicitud) cuando intenta obtener un recurso para evitar que ese método de solicitud se aplique a un recurso fuera de su deseo. |
| 413 |
El servidor se niega a procesar la solicitud actual porque la longitud de los datos del cuerpo de la entidad presentada supera el rango que el servidor está dispuesto a o puede manejar. En esta situación, el servidor puede cerrar la conexión para evitar que el cliente continúe enviando esta solicitud. Si esta situación es temporal, el servidor debe devolver un encabezado de respuesta Retry-After para informar al cliente cuánto tiempo debe esperar antes de intentar nuevamente. |
| 414 |
La longitud del URI solicitado excede la longitud que el servidor puede interpretar y, por lo tanto, el servidor se niega a servir la solicitud. Esto es raro y las situaciones típicas incluyen: cuando una presentación de formulario que debería haber utilizado el método POST se convierte en una solicitud GET, provocando que la cadena de consulta (Query String) sea demasiado larga. URI redirigidos en "agujeros negros", por ejemplo, si cada redirección utiliza la antigua URI como parte de la nueva URI, llevando a una longitud de URI excesiva después de múltiples redirecciones. El cliente está tratando de explotar vulnerabilidades de seguridad que existen en el servidor. Este tipo de servidores utiliza un búfer de longitud fija para leer o manipular el URI de la solicitud, y cuando los parámetros después de GET superan cierto valor, puede resultar en un desbordamiento de búfer que genera la ejecución de código arbitrario[1]. Los servidores sin estas vulnerabilidades deben retornar el código de estado 414. |
| 415 |
Para el método de solicitud actual y el recurso solicitado, la entidad presentada en la solicitud no es un formato que el servidor admite y, por lo tanto, se rechaza la solicitud. |
| 416 |
Si la solicitud incluye el encabezado de solicitud Range, y cualquiera de los rangos de datos especificados en Range no se superpone con el rango disponible del recurso actual y además la solicitud no define el encabezado If-Range, entonces el servidor debe devolver el código de estado 416. Si Range utiliza rangos de bytes, esta condición indica que la posición inicial del primer byte del rango solicitado excede la longitud del recurso actual. El servidor también debe incluir un encabezado de entidad Content-Range en la respuesta que indique la longitud actual del recurso. Esta respuesta también prohíbe el uso de multipart/byteranges como su Content-Type. |
| 417 |
El contenido esperado especificado en el encabezado Expect no puede ser satisfecho por el servidor, o este servidor es un servidor proxy que tiene evidencia clara de que el contenido de Expect no puede ser satisfecho en el siguiente nodo en la ruta actual. |
| 421 |
El número de conexiones desde la dirección IP del cliente actual hacia el servidor ha superado el máximo permitido por el servidor. Normalmente, esta dirección IP hace referencia a la dirección del cliente vista desde el servidor (por ejemplo, la dirección de un gateway o de un servidor proxy del usuario). En esta situación, el conteo de conexiones puede involucrar a más de un usuario final. |
| 422 |
El formato de la solicitud es correcto, pero no se puede responder debido a un error semántico. (RFC 4918 WebDAV) 423 Locked El recurso actual está bloqueado. (RFC 4918 WebDAV) |
| 424 |
El actual fallo de la solicitud se debió a un error en una solicitud anterior, como un PROPPATCH. (RFC 4918 WebDAV) |
| 425 |
Definido en el borrador de WebDav Advanced Collections, pero no aparece en el "Protocolo de Colecciones Secuenciales de WebDAV" (RFC 3658). |
| 426 |
El cliente debe cambiar a TLS/1.0. (RFC 2817) |
| 449 |
Exclusivo de Microsoft, indica que la solicitud debe ser reintentada después de que se complete la acción apropiada. |
| 500 |
El servidor encontró una condición inesperada que le impidió completar el manejo de la solicitud. Generalmente, este problema ocurre cuando hay errores en el código del programa del servidor. |
| 501 |
El servidor no admite cierta funcionalidad que requiere la solicitud actual. Cuando el servidor no puede entender el método de solicitud y no puede soportar la solicitud para ningún recurso. |
| 502 |
El servidor que actúa como puerta de enlace o proxy recibió una respuesta no válida del servidor aguas arriba al intentar ejecutar la solicitud. |
| 503 |
El servidor no puede manejar la solicitud en este momento debido a sobrecarga o mantenimiento temporal del servidor. Esta situación es temporal y se restablecerá después de un tiempo. Si se puede prever el tiempo de retraso, la respuesta puede contener un encabezado Retry-After para indicar este tiempo de retraso. Si no se proporciona esta información de Retry-After, el cliente debe manejarlo de la misma manera que un error 500. Nota: La existencia del código de estado 503 no significa que el servidor deba usarlo durante la sobrecarga. Algunos servidores simplemente desean rechazar la conexión del cliente. |
| 504 |
El servidor que actúa como puerta de enlace o proxy no recibió una respuesta a tiempo del servidor aguas arriba (servidor identificado por URI, por ejemplo, HTTP, FTP, LDAP) o del servidor auxiliar (por ejemplo, DNS) al intentar ejecutar la solicitud. Nota: Algunos servidores proxy devuelven un error 400 o 500 cuando se agota el tiempo de espera de la consulta 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 usar la misma versión que el cliente. La respuesta debe incluir un cuerpo que explique por qué la versión no es compatible y qué protocolos admite el servidor. |
| 506 |
Expansión de "Protocolo de Negociación de Contenidos Transparente" (RFC 2295). Indica un error de configuración interno del servidor: el recurso del parámetro de negociación solicitado se ha configurado para usar él mismo en la negociación de contenido transparente, por lo que no es un foco adecuado en un proceso de negociación. |
| 507 |
El servidor no puede almacenar el contenido necesario para completar la solicitud. Esta situación se considera temporal. WebDAV (RFC 4918) |
| 509 |
El servidor alcanzó el límite de ancho de banda. Este no es un código de estado oficial, pero aún se usa ampliamente. |
| 510 |
La política que se necesita para obtener el recurso no se ha satisfecho. (RFC 2774) |