| Códigos de estado HTTP | Significado de los códigos de estado |
|---|
| 100 | El cliente debe continuar enviando solicitudes. Esta respuesta temporal se utiliza para notificar al cliente de que parte de su solicitud ya 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 ha completado, ignorar esta respuesta. El servidor debe enviar una respuesta final al cliente una vez completada la solicitud. |
| 101 | El servidor ha entendido la solicitud del cliente y notificará al cliente a través del encabezado de mensaje Upgrade para utilizar un protocolo diferente para completar esta solicitud. Después de enviar la última línea en blanco de esta respuesta, el servidor cambiará a los protocolos definidos en el encabezado de Upgrade. Solamente se debe tomar esta medida cuando sea más ventajoso cambiar a un nuevo protocolo. Por ejemplo, cambiar a una nueva versión de HTTP que sea más ventajosa que la versión antigua, o cambiar a un protocolo en tiempo real y sincronizado para transmitir recursos que utilicen estas características. |
| 102 | por WebDAV (RFC 2518）códigos de estado extendidos, que representan que el procesamiento se continuará. |
| 2Error 00 | La solicitud se ha procesado con éxito y la cabecera o el cuerpo de datos esperados se devolverán con esta respuesta. |
| 201 | La solicitud se ha implementado y se ha creado un nuevo recurso según las necesidades de la solicitud, y su URI se ha devuelto en la información de encabezado de ubicación. Si el recurso necesario no se puede crear de manera oportuna, se debe devolver'202 'Aceptado'. |
| 202 | El servidor ha aceptado la solicitud, pero no ha procesado. Al igual que podría ser rechazada, esta solicitud podría o no ser ejecutada finalmente. En el caso de operaciones asincrónicas, no hay nada más conveniente que enviar este código de estado. Devolver202El objetivo del código de estado es permitir que el servidor acepte solicitudes de otros procesos (por ejemplo, operaciones basadas en lotes que se ejecutan una vez al día), sin mantener la conexión del cliente con el servidor hasta que se complete toda la operación de lote. Después de procesar la solicitud y devolver202El código de estado debe incluir en la entidad devuelta algunas indicaciones sobre el procesamiento actual y punteros a monitores o predicciones de estado de procesamiento 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 metadatos del encabezado de entidad devuelta no es un conjunto determinado válido 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 del recurso pueden hacer que el servidor original conozca el superconjunto de la información metadatos. El uso de este código de estado no es obligatorio y solo se debe usar cuando la respuesta no usaría este código de estado.2solo en el caso de 00 OK es apropiado. |
| 204 | El servidor ha procesado con éxito la solicitud, pero no necesita devolver ningún contenido de entidad y desea devolver información metadatos actualizada. La información metadatos nueva o actualizada puede devolverse en forma de encabezados de entidad. Si existen estos encabezados, deben coincidir con las variables solicitadas. Si el cliente es un navegador, el navegador del usuario debe mantener la página que envió la solicitud sin producir cambios en la vista del documento, incluso si según la especificación la información metadatos nueva o actualizada debería aplicarse al documento de la vista activa del navegador. Debido a204La respuesta no debe contener ningún cuerpo de mensaje, por lo que siempre termina con el primer salto de línea en blanco después del encabezado del mensaje. |
| 205 | El servidor procesó con éxito la solicitud y no devolvió ningún contenido. Pero con 204El servidor ha procesado con éxito la solicitud y no ha devuelto ningún contenido. Pero con204La respuesta también se prohíbe contener cualquier cuerpo de mensaje y termina con la primera línea en blanco después de los encabezados de mensaje. Si las respuestas son diferentes, las respuestas que devuelven este código de estado requieren que el remitente restablezca la vista del documento. Esta respuesta se utiliza principalmente después de que el usuario ingresa datos, para restablecer el formulario de inmediato, permitiendo al usuario comenzar otra entrada fácilmente. Con |
| 206 | El servidor ha procesado con éxito la solicitud GET parcial. Herramientas de descarga HTTP como FlashGet o Xunlei utilizan este tipo de respuesta para implementar la transferencia de puntos de ruptura o dividir un gran documento en múltiples segmentos de descarga simultáneamente. Esta solicitud debe incluir la información del encabezado Range para indicar el rango de contenido que desea el cliente, y puede incluir If-La respuesta debe incluir los siguientes dominios de encabezado: Content-Range se utiliza para indicar el rango de contenido devuelto en esta respuesta; si el rango de contenido se utiliza como condición de solicitud Content-Type multipart/byteranges, cada segmento multipart debe contener el encabezado Content-El dominio Range se utiliza para indicar el rango de contenido de este segmento. Si la respuesta contiene varios segmentos de descarga de Content-Longitud, entonces su valor debe coincidir con el número real de bytes del rango de contenido devuelto. Fecha ETag y/o Content-Location, si la solicitud similar debería devolver200 respuesta. Expires, Cache-Control, y/o Vary, si su valor puede ser diferente del valor correspondiente de otras respuestas de variables anteriores. Si la solicitud de esta respuesta utilizó If-o Vary, si su valor puede ser diferente del valor correspondiente de otras respuestas de variables anteriores. Si la solicitud de esta respuesta utilizó If-que deben devolverse. Si se realiza una verificación de caché fuerte de Range, la respuesta actual no debe contener otros encabezados de entidad; si la solicitud de esta respuesta utilizó If2En la respuesta 00 deben devolverse todos los dominios de encabezado de entidad. Si se realiza una verificación de caché débil de Range, la respuesta actual no debe contener otros encabezados de entidad; esto evita que haya inconsistencias entre el contenido almacenado en caché y la información actualizada de los encabezados de entidad. De lo contrario, esta respuesta debe contener todos los encabezados de entidad-Modified, el caché del cliente debe prohibir almacenar206El contenido devuelto de la respuesta se combina con cualquier contenido almacenado en caché anterior. Si el cliente no admite Range y no puede coincidir con el encabezado Content-El encabezado Range se prohíbe almacenar en caché.206el contenido devuelto de la respuesta. |
| 207 | WebDAV (RFC 2518el código de estado extendido, lo que indica que el cuerpo de la mensaje siguiente será un mensaje XML y puede contener una serie de códigos de respuesta independientes según la cantidad de sub solicitudes anteriores. |
| 3Error 00 | El recurso solicitado tiene una serie de información de retroalimentación disponible, cada una con una dirección específica y información de negociación impulsada por el navegador. El usuario o el navegador pueden seleccionar una dirección preferida para la redirección. A menos que sea una solicitud HEAD, la respuesta debe incluir una entidad de lista de características y direcciones del recurso para que el usuario o el navegador pueda seleccionar la dirección de redirección más adecuada. El formato de esta entidad es especificado por el contenido-Type define el formato. Los navegadores pueden tomar la decisión más adecuada automáticamente basándose en el formato de la respuesta y las capacidades del navegador. Por supuesto, RFC 2616La especificación no regula cómo debe realizarse esta elección automática. Si el servidor ya tiene una opción de retroalimentación preferida, debe especificarse esta URI de retroalimentación en Location; el navegador puede usar este valor de Location como la dirección de redirección automática. Además, a menos que se especifique adicionalmente, esta respuesta también es almacenable en caché. |
| 301 | El recurso solicitado se ha movido permanentemente a una nueva ubicación y todas las referencias futuras a este recurso deben usar uno de los URI devueltos en esta respuesta. Si es posible, los clientes con capacidad de edición de enlaces deben modificar automáticamente la dirección de la solicitud a la dirección devuelta por el servidor. A menos que se especifique adicionalmente, esta respuesta también es almacenable en caché. El nuevo URI permanente debe devolverse en el dominio Location de la respuesta. A menos que sea una solicitud HEAD, la entidad de la respuesta debe contener un enlace hipertexto hacia el nuevo URI y una breve explicación. Si no es una solicitud GET o HEAD, por lo tanto, el navegador no permite la redirección automática a menos que se confirme el usuario, ya que las condiciones de la solicitud pueden cambiar. Nota: Para ciertos navegadores que utilizan HTTP/1.0 los navegadores, cuando envían solicitudes POST que reciben una301La respuesta, la solicitud de redirección siguiente se convertirá en GET. |
| 302 | El recurso solicitado se responde temporalmente desde un URI diferente. Debido a que esta redirección es temporal, el cliente debe continuar enviando solicitudes posteriores a la dirección original. Solo en el caso de que Cache-Control o Expires se especifican, esta respuesta es almacenable en caché. El nuevo URI temporal debe devolverse en el dominio Location de la respuesta. A menos que sea una solicitud HEAD, la entidad de la respuesta debe contener un enlace hipertexto hacia el nuevo URI y una breve explicación. Si no es una solicitud GET o HEAD, el navegador no permite la redirección automática a menos que se confirme el usuario, ya que las condiciones de la solicitud pueden cambiar. Nota: Aunque RFC 1945y RFC 2068La especificación no permite que el cliente cambie el método de la solicitud durante la redirección, pero muchos navegadores existentes302La respuesta se considera303la respuesta, y acceder al URI especificado en Location utilizando el método GET, sin importar el método de la solicitud original. El código de estado303y307se ha añadido para aclarar qué reacción espera el servidor del cliente. |
| 303 | La respuesta correspondiente a la solicitud actual puede encontrarse en otro URI, y el cliente debe acceder a ese recurso utilizando el método GET. La existencia de este método es principalmente para permitir que las solicitudes POST activadas por scripts se redirijan a un nuevo recurso. Este nuevo URI no es una referencia de sustitución del recurso original. Al mismo tiempo,303La respuesta no debe almacenarse en caché. Por supuesto, la segunda solicitud (redirección) puede almacenarse en caché. El nuevo URI debe devolverse en el dominio Location de la respuesta. A menos que sea una solicitud HEAD, la entidad de la respuesta debe contener un enlace hipertexto hacia el nuevo URI y una breve explicación. Nota: Muchos HTTP/1.1versiones anteriores de los navegadores no pueden entender303estado. Si es necesario considerar la interacción con estos navegadores,302el código de estado debe ser suficiente, porque la mayoría de los navegadores manejan302la manera en que la respuesta se realiza es exactamente la forma en que el cliente debe manejarlo según la especificación.303lo que debe hacer al recibir la respuesta. |
| 304 | si el cliente envió una solicitud GET condicional y esta solicitud fue permitida, y el contenido del documento (desde la última visita o según las condiciones de la solicitud) no ha cambiado, entonces el servidor debe devolver este código de estado.304la respuesta no debe contener el cuerpo del mensaje, por lo que siempre termina con la primera línea en blanco después de los encabezados del mensaje. Esta respuesta debe contener los siguientes encabezados: Date, a menos que este servidor no tenga un reloj. Si el servidor sin reloj también cumple con estas reglas, entonces los servidores proxy y los clientes pueden agregar el campo Date a los encabezados de respuesta recibidos (como RFC 2068especificado, el mecanismo de caché funcionará normalmente. ETag y/o Content-Location, si la solicitud debe devolver200 respuesta. Expires, Cache-Control, y/o Vary, si su valor puede ser diferente de los valores de otras respuestas correspondientes a la misma variable. Si esta respuesta solicitó el uso de una verificación de caché fuerte, entonces esta respuesta no debe contener otras cabeceras de entidad; de lo contrario (por ejemplo, una solicitud GET condicional que utiliza una verificación de caché débil), esta respuesta no debe contener otras cabeceras de entidad; esto evita que haya inconsistencias entre el contenido de la entidad en caché y las cabeceras de entidad actualizadas. Si alguna304la respuesta indica que una entidad específica no está en caché, entonces el sistema de caché debe ignorar esta respuesta y repetir la solicitud sin restricciones. Si se recibe una solicitud que requiere actualizar una entrada de caché304la respuesta, entonces el sistema de caché debe actualizar toda la entrada para reflejar los valores de todos los campos actualizados en la respuesta. |
| 305 | El recurso solicitado debe ser accesible a través del agente especificado. La información del URI del agente especificado se proporcionará en el campo Location, y el destinatario debe enviar una solicitud individual para acceder al recurso a través de este agente. Solo el servidor original puede establecer305la respuesta. Nota: RFC 2068no hay nada claro305la respuesta es para redirigir una solicitud individual y solo puede ser establecida por el servidor original. Ignorar estos límites puede llevar a consecuencias de seguridad graves. |
| 306 | en la última versión de la norma,306el código de estado ya no se utiliza. |
| 307 | El recurso solicitado se responde temporalmente desde un URI diferente. Debido a que esta redirección es temporal, el cliente debe continuar enviando solicitudes posteriores a la dirección original. Solo en el caso de que Cache-En el caso de que se especifique en Control o Expires, esta respuesta es cacheable. El nuevo URI temporal debe devolverse en el campo Location de la respuesta. A menos que sea una solicitud HEAD, la entidad de la respuesta debe contener un enlace hipertexto y una breve descripción que apunte al nuevo URI. Porque algunos navegadores no pueden identificar307La respuesta, por lo que es necesario agregar la información necesaria para que el usuario pueda entender y hacer una solicitud de acceso al nuevo URI. Si no es una solicitud GET o HEAD, el navegador no permite la redirección automática a menos que se confirme por el usuario, ya que las condiciones de la solicitud pueden cambiar por esta razón. |
| 4Error 00 | 1La semántica es incorrecta, la solicitud actual no puede ser entendida por el servidor. A menos que se modifique, el cliente no debe presentar esta solicitud repetidamente.2Los parámetros de solicitud son incorrectos. |
| 401 | La solicitud actual requiere autenticación del usuario. La respuesta debe contener una cabecera WWW-Authenticate adecuada para el recurso solicitado-cabecera de información Authenticate para preguntar por información del usuario. El cliente puede presentar repetidamente una solicitud que contenga la cabecera de información Authorization adecuada. Si la solicitud actual ya contiene un certificado de Authorization, entonces401La respuesta representa que el servidor ha validado y rechazado los certificados. Si401La respuesta contiene la misma solicitud de autenticación que la respuesta anterior y el navegador ha intentado al menos una vez la autenticación, entonces el navegador debe mostrar al usuario la información del cuerpo de respuesta que contiene, ya que esta información puede contener información de diagnóstico relevante. Ver RFC 2617 |
| 402 | Este código de estado se reserva para futuras necesidades posibles. |
| 403 | El servidor ha entendido la solicitud, pero la ha rechazado. Con401La diferencia con la respuesta es que la autenticación no ofrece ninguna ayuda y esta solicitud no debe ser presentada repetidamente. Si no es una solicitud HEAD y el servidor desea explicar por qué no se puede ejecutar la solicitud, debe describir la razón de rechazo en el cuerpo. Por supuesto, el servidor también puede devolver una404respuesta, si no desea que el cliente obtenga alguna información. |
| 404 | La solicitud falló, el recurso solicitado no se encontró en el servidor. No hay información que pueda informar al usuario si esta condición es temporal o permanente. Si el servidor conoce la situación, debe usar410Código de estado para informar que el recurso antiguo ya no está disponible permanentemente debido a problemas internos de configuración y no hay direcciones de redirección disponibles.404Este código de estado se utiliza ampliamente cuando el servidor no desea revelar la razón por la que se deniega la solicitud o no hay otra respuesta adecuada disponible. |
| 405 | El método especificado en la línea de solicitud no puede ser utilizado para solicitar el recurso correspondiente. La respuesta debe devolver una información de cabecera Allow para indicar la lista de métodos que el recurso puede aceptar. Dado que los métodos PUT y DELETE realizan operaciones de escritura en los recursos del servidor, la mayoría de los servidores web no lo admiten o no lo permiten por defecto, y para dichas solicitudes se devuelve405Error. |
| 406 | La característica del contenido del recurso solicitado no puede satisfacer las condiciones especificadas en la cabecera de la solicitud, por lo tanto, no se puede generar el cuerpo de respuesta. A menos que sea una solicitud HEAD, esta respuesta debe devolver un cuerpo que contenga una lista de características y direcciones que permiten al usuario o al navegador elegir la más adecuada. El formato del cuerpo se determina por el contenido de la cabecera Content-Type.-El tipo de medio definido en la cabecera Type determina. El navegador puede hacer la mejor elección según el formato y sus propias capacidades. Sin embargo, la especificación no define ningún estándar para realizar此种选择。 |
| 407 | Con401La respuesta es similar, pero el cliente debe autenticarse en el servidor proxy. El servidor proxy debe devolver una Proxy-Authenticate se utiliza para realizar preguntas de autenticación. El cliente puede devolver una Proxy-La información de cabecera Authorization se utiliza para verificar. Ver RFC 2617 |
| 408 | Tiempo de espera de solicitud. El cliente no ha completado el envío de una solicitud en el tiempo que el servidor espera. El cliente puede presentar esta solicitud nuevamente en cualquier momento sin realizar cambios. |
| 409 | Debido a que hay un conflicto entre el estado actual del recurso solicitado, la solicitud no se puede completar. Este código solo se puede usar en situaciones donde se considera que el usuario puede resolver el conflicto y presentará una nueva solicitud. Esta respuesta debe contener suficiente información para que el usuario pueda descubrir la causa del conflicto. Los conflictos suelen ocurrir en el procesamiento de solicitudes PUT. Por ejemplo, en un entorno de verificación de versiones, si la información de versión adjunta a una solicitud de modificación de recursos específicos en un PUT conflicta con alguna solicitud (tercera parte) anterior, el servidor debe devolver una409Error, informando al usuario de que la solicitud no se puede completar. En este momento, es probable que la entidad de respuesta contenga una comparación de diferencias entre dos versiones conflictivas, para que el usuario pueda presentar una nueva versión después de la fusión. |
| 410 | El recurso solicitado ya no está disponible en el servidor y no hay ninguna dirección de redirección conocida. Este estado debe considerarse permanente. Si es posible, los clientes con funciones de edición de 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 este estado es permanente, debe usar404Código de estado. A menos que se especifique lo contrario, esta respuesta es cachable.410El propósito principal de la respuesta es ayudar a los administradores de sitios web a mantener el sitio, notificar a los usuarios de que este recurso ya no está disponible y que el propietario del servidor desea que se eliminen todas las conexiones remotas que apuntan a este recurso. Este tipo de evento es muy común en servicios limitados y de valor agregado. Del mismo modo,410La respuesta también se utiliza para notificar al cliente que en el sitio actual del servidor, los recursos que originalmente pertenecían a alguien ya no están disponibles. Por supuesto, si es necesario marcar todos los recursos permanentemente no disponibles como410 El estado 'Gone', así como el tiempo que debe mantenerse este marcador, depende completamente del propietario del servidor. |
| 411 | El servidor rechaza la solicitud sin definir Content.-Aceptar la solicitud en el caso de la cabecera Length. Al agregar un contenido válido que indique la longitud del mensaje de solicitud.-Después de la cabecera Length, el cliente puede presentar nuevamente la solicitud. |
| 412 | El servidor no pudo satisfacer una o más condiciones previas cuando verificaba las cabeceras de solicitud. Este código de estado permite al cliente establecer condiciones previas en la información metadatos (datos de cabecera de solicitud) al solicitar recursos, para evitar que el método de solicitud se aplique a recursos以外的 contenido que desea. |
| 413 | El servidor rechaza procesar la solicitud actual porque el tamaño de los datos de la entidad presentada en la solicitud excede el rango que el servidor está dispuesto o puede 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 un Retry-Después de la cabecera de respuesta, para informar al cliente cuánto tiempo puede esperar antes de intentar de nuevo. |
| 414 | La longitud de la URI solicitada ha excedido la longitud que el servidor puede explicar, por lo que el servidor ha rechazado proporcionar servicios para esta solicitud. Esto es raro, y las situaciones habituales incluyen: el envío de un formulario utilizando el método POST que se convirtió en GET, lo que hizo que la cadena de consulta (Query String) fuera demasiado larga. URI de redirección de 'agujero negro', por ejemplo, cada redirección toma la URI antigua como parte de la nueva URI, lo que lleva a que la URI sea demasiado larga después de varias redirecciones. El cliente está intentando aprovechar ciertas vulnerabilidades de seguridad existentes en los servidores para atacar el servidor. Estos servidores utilizan buffers de longitud fija para leer o operar con la URI solicitada, y cuando los parámetros GET después de un cierto valor pueden causar un desbordamiento de búfer, lo que lleva a la ejecución de código arbitrario [1]。Los servidores que no tienen este tipo de vulnerabilidad deben devolver414El código de estado。 |
| 415 | Para el método de solicitud actual y el recurso solicitado, la entidad presentada en la solicitud no es un formato admitido por el servidor, por lo que se rechaza la solicitud. |
| 416 | Si la solicitud contiene la cabecera de solicitud Range y cualquier rango de datos especificado en Range no coincide con el rango disponible del recurso actual, y no se define If-Si la solicitud contiene la cabecera de solicitud Range, el servidor debe devolver416El código de estado. Si el rango utilizado por Range es el rango de bytes, en este caso se refiere a que la posición del primer byte del rango especificado en la solicitud excede la longitud del recurso actual. El servidor también debe devolver416Al mismo tiempo, contiene un Content-La cabecera de entidad Range, utilizada para indicar la longitud del recurso actual. Esta respuesta también está prohibida para usar multipart/byteranges como su contenido de Content-Type。 |
| 417 | El contenido esperado especificado en la cabecera de solicitud Expect no puede ser satisfecho por el servidor, o este servidor es un servidor proxy que tiene evidencia clara de que el contenido Expect no puede ser satisfecho en el siguiente nodo del enrutamiento actual. |
| 421 | El número de conexiones desde la dirección IP del cliente actual al servidor ha superado el rango máximo permitido por el servidor. Por lo general, aquí la dirección IP 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 cálculo del número de conexiones puede involucrar más de un usuario final. |
| 422 | El número de conexiones desde la dirección IP del cliente actual al servidor ha superado el rango máximo permitido por el servidor. Por lo general, aquí la dirección IP 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 cálculo del número de conexiones puede involucrar más de un usuario final. |
| 422 | La solicitud tiene un formato correcto, pero debido a errores semánticos, no se puede responder. (RFC 4918 WebDAV)423 El recurso actual está bloqueado. (RFC 4918 WebDAV) |
| 424 | Debido a un error en una solicitud anterior, la solicitud actual ha fallado, por ejemplo PROPPATCH. (RFC 4918 WebDAV) |
| 425 | Definido en el borrador de Colecciones Avanzadas de WebDav, pero no aparece en el Protocolo de Conjuntos Secuenciales de WebDAV (RFC 3658) |
| 426 | El cliente debe cambiar a TLS/1.0. (RFC 2817) |
| 449 | Expandido por Microsoft, representa que la solicitud debe realizarse después de completar la operación adecuada. |
| 5Error 00 | El servidor se enfrenta a una condición inesperada que le impide completar el procesamiento de la solicitud. Generalmente, este problema ocurre cuando hay un error en el código del programa del servidor. |
| 501 | El servidor no admite alguna función necesaria para la solicitud actual. Cuando el servidor no puede identificar el método de solicitud y no puede admitir cualquier solicitud de recursos. |
| 502 | Cuando un servidor que actúa como gateway o proxy intenta ejecutar una solicitud y recibe una respuesta inválida del servidor superior. |
| 503 | Debido a la mantenimiento temporal del servidor o sobrecarga, el servidor no puede procesar la solicitud en este momento. Esta condición es temporal y se restablecerá en un momento posterior. Si se puede prever el tiempo de demora, la respuesta puede incluir un Retry-Después de la cabecera para indicar este tiempo de retraso. Si no se proporciona este Retry-Después de la información, el cliente debe procesar500 para manejar la respuesta. Nota:503La existencia de un código de estado no significa que el servidor debe usarlo cuando está sobrecargado. Algunos servidores solo desean rechazar la conexión del cliente. |
| 504 | Cuando un servidor que actúa como gateway o proxy intenta ejecutar una solicitud y no recibe una respuesta oportuna del servidor superior (el servidor identificado por URI, por ejemplo HTTP, FTP, LDAP) o del servidor auxiliar (por ejemplo DNS), por ejemplo, algunos servidores proxy devolverán400 o5Error 00 |
| 505 | El servidor no admite o rechaza admitir la versión de HTTP utilizada en la solicitud. Esto sugiere que el servidor no puede o no desea usar la misma versión que el cliente. La respuesta debe incluir un ente que describa por qué la versión no se admite y qué protocolos admite el servidor. |
| 506 | por el Protocolo de Negociación de Contenido Transparente (RFC 2295) extensión, que representa que el servidor tiene un error de configuración interna: el recurso de argumento negociado solicitado se ha configurado para usarlo mismo en la negociación de contenido transparente, por lo que no es un punto de interés adecuado 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 el límite de ancho de banda. Este no es un código de estado oficial, pero se utiliza ampliamente. |
| 510 | La estrategia necesaria para obtener recursos no ha sido satisfecha. (RFC 2774) |
