Caja de herramientas iToolify
Código de estado HttpSignificado del código de estado
100El cliente debe continuar enviando la solicitud. Esta respuesta temporal se utiliza para informar al cliente 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 solicitud o ignorar esta respuesta si la solicitud se ha completado. El servidor debe enviar una respuesta final al cliente después de completar la solicitud.
101El servidor ha entendido la solicitud del cliente y notificará al cliente a través del encabezado de mensaje de Upgrade que se utiliza 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 del mensaje de Upgrade. Se deben tomar medidas similares solo cuando sea más beneficioso cambiar a un nuevo protocolo. Por ejemplo, cambiar a una nueva versión de HTTP tiene una ventaja sobre la versión anterior, o cambiar a un protocolo en tiempo real y sincronizado para transferir recursos que aprovechan tales características.
102El código de estado extendido por WebDAV(RFC 2518) significa que el procesamiento continuará.
200La solicitud se ha realizado correctamente y el encabezado de respuesta o el cuerpo de datos deseado de la solicitud se devolverá con esta respuesta.
201La solicitud se ha implementado y se ha establecido un nuevo recurso de acuerdo con las necesidades de la solicitud, y su URI se ha devuelto con la información del encabezado de ubicación. Si los recursos necesarios no se pueden establecer a tiempo, se debe devolver '202 Accepted'.
202El servidor aceptó la solicitud, pero aún no la ha procesado. Al igual que puede ser denegada, eventualmente la solicitud puede o no ejecutarse. En el caso de una operación asincrónica, no hay forma más conveniente que enviar este código de estado. El propósito de la respuesta que devuelve el código de estado 202 es permitir que el servidor acepte solicitudes de otros procesos (por ejemplo, una operación basada en lotes que solo se ejecuta una vez al día) sin tener que mantener al cliente conectado al servidor hasta que se complete la operación por lotes. La respuesta al aceptar el procesamiento de la solicitud y devolver el código de estado 202 debe contener alguna información que indique el estado actual del procesamiento en la entidad devuelta, así como un puntero al monitor de estado de procesamiento o predicción de estado para que el usuario pueda estimar si la operación se ha completado.
203El servidor ha procesado con éxito la solicitud, pero la metainformación del encabezado de la entidad devuelta no es un conjunto de determinaciones 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 superconjunto de la versión original. Por ejemplo, los metadatos que contienen un recurso pueden hacer que el servidor de origen conozca el super de la metainformación. El uso de este código de estado no es necesario y solo es apropiado si la respuesta devuelve 200 OK sin usar este código de estado.
204El servidor procesó la solicitud con éxito, pero no necesita devolver ningún contenido físico y desea devolver metainformación actualizada. La respuesta puede devolver metainformación nueva o actualizada en forma de un encabezado sólido. Si esta información de cabecera está presente, debe hacerse eco de la variable solicitada. Si el cliente es un navegador, entonces el navegador del usuario debe conservar la página que envió la solicitud sin ningún cambio en la vista del documento, incluso si la metainformación nueva o actualizada de acuerdo con la especificación debe aplicarse a la actividad del navegador del usuario. El documento en la vista. Dado que la respuesta 204 tiene prohibido contener cualquier cuerpo de mensaje, siempre termina con la primera línea en blanco después del encabezado del mensaje.
205El servidor procesó correctamente la solicitud y no devolvió nada. 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. La respuesta se utiliza principalmente para restablecer el formulario inmediatamente después de aceptar la entrada del usuario para que el usuario pueda iniciar fácilmente otra entrada. Al igual que con la respuesta 204, la respuesta también tiene prohibido incluir cualquier cuerpo de mensaje y termina con la primera línea en blanco después del encabezado del mensaje.
206El servidor ha procesado con éxito parte de las solicitudes GET. Herramientas de descarga HTTP similares a FlashGet o Xunlei utilizan este tipo de respuestas para implementar la reanudación de las descargas o para dividir un archivo grande en múltiples segmentos que se descargan simultáneamente. La solicitud debe incluir el encabezado Range para indicar el rango de contenido que el cliente desea obtener, y puede incluir también el encabezado If-Range como condición de la solicitud. La respuesta debe incluir los siguientes campos de cabecera: Content-Range, para indicar el rango de contenido devuelto en esta respuesta; y, si el campo Content-Type es multipart/byteranges para una descarga por fragmentos, cada parte del tipo multipart debe incluir también un campo Content-Range que indique el rango de contenido de esa parte. Si la respuesta contiene el encabezado Content-Length, su valor debe coincidir con el número real de bytes del intervalo de contenido que se está devolviendo. Fecha, ETag y/o Content-Location, en caso de que la misma solicitud debiera haber devuelto una respuesta 200. Expires, Cache-Control y/o Vary, en caso de que sus valores puedan diferir de los correspondientes a otras respuestas de la misma variable.Si la solicitud correspondiente a esta respuesta utilizó la validación de caché fuerte mediante el encabezado If-Range, entonces esta respuesta no debe incluir otros encabezados de entidad; si, por el contrario, la solicitud empleó la validación de caché débil con dicho encabezado, está prohibido que la respuesta contenga otros encabezados de entidad. Esto evita la inconsistencia entre el contenido de la entidad almacenada en caché y la información actualizada de los encabezados de entidad. De lo contrario, esta respuesta debe incluir todos los campos de cabecera de entidad que deberían haberse devuelto en una respuesta con código 200. Si las cabeceras ETag o Last-Modified no coinciden con precisión, el caché del cliente debe impedir la combinación del contenido devuelto en una respuesta 206 con cualquier contenido previamente almacenado en caché. Cualquier caché que no admita las cabeceras Range y Content-Range está prohibida de almacenar en caché el contenido devuelto en una respuesta 206.
207El código de estado extendido por WebDAV(RFC 2518) significa que el siguiente cuerpo de mensaje será un mensaje XML y puede contener una serie de códigos de respuesta independientes dependiendo del número de subsolicitudes anteriores.
300Los recursos solicitados tienen una serie de comentarios para elegir, cada uno con su propia dirección específica e información de negociación impulsada por el navegador. El usuario o el navegador pueden elegir una dirección preferida para redirigir. A menos que se trate de una solicitud HEAD, la respuesta debe incluir una entidad de una lista de características de recursos y direcciones para que el usuario o el navegador seleccione la dirección de redirección más adecuada. El formato de esta entidad está determinado por el formato definido por Content-Type. El navegador puede tomar automáticamente la decisión más adecuada en función del formato de respuesta y las propias capacidades del navegador. Por supuesto, la especificación RFC 2616 no especifica cómo debe realizarse dicha selección automática. Si el propio servidor ya tiene la opción de retroalimentación preferida, el URI de esta retroalimentación debe indicarse en Location; el navegador puede usar este valor de Location como la dirección redirigida automáticamente. Además, esta respuesta también se puede almacenar en caché a menos que se especifique adicionalmente.
301El 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 en esta respuesta. Si es posible, el cliente con función de edición de enlaces debe modificar automáticamente la dirección solicitada a la dirección devuelta por el servidor. Salvo especificación adicional, esta respuesta también es cachable. El nuevo URI permanente debe devolverse en el campo Location de la respuesta. A menos que se trate de una solicitud HEAD, la entidad de la respuesta debe incluir un hipervínculo al nuevo URI junto con una breve explicación. Si esta no es una solicitud GET ni HEAD, el navegador prohíbe la redirección automática a menos que el usuario lo confirme, ya que las condiciones de la solicitud podrían cambiar como resultado. Atención: Para algunos navegadores que utilizan el protocolo HTTP/1.0, si la solicitud POST que envían recibe una respuesta 301, la solicitud de redirección siguiente se convertirá en una solicitud GET.
302El recurso solicitado ahora responde temporalmente a la solicitud desde un URI diferente. Dado que dicha redirección es temporal, el cliente debe continuar enviando solicitudes posteriores a la dirección original. Esta respuesta solo se puede almacenar en caché si se especifica en Cache-Control o Expires. El nuevo URI temporal debe ser devuelto en el dominio Location de la respuesta. A menos que se trate de una solicitud HEAD, la entidad que responde debe incluir un hipervínculo al nuevo URI y una breve descripción. Si no se trata de una solicitud GET o HEAD, entonces el navegador prohíbe la redirección automática a menos que sea confirmada por el usuario, ya que las condiciones de la solicitud pueden cambiar. Nota: Aunque las especificaciones RFC 1945 y RFC 2068 no permiten que el cliente cambie el método de solicitud durante la redirección, muchos navegadores existentes consideran la respuesta 302 como una respuesta 303 y usan GET para acceder al URI especificado en Location, ignorando el método solicitado originalmente. Los códigos de estado 303 y 307 se agregan para aclarar qué tipo de reacción espera el servidor del cliente.
303La 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 el script se redirija a un nuevo recurso. Este nuevo URI no es una referencia alternativa al recurso original. Mientras tanto, la respuesta 303 está prohibida para ser almacenada en caché. Por supuesto, la segunda solicitud (redirección) puede almacenarse en caché. El nuevo URI debe ser devuelto en el dominio Location de la respuesta. A menos que se trate de una solicitud HEAD, la entidad que responde debe incluir un hipervínculo al nuevo URI y una breve descripción. Nota: Muchos navegadores anteriores de la versión HTTP/1.1 no entienden correctamente el estado 303. Si necesita considerar la interacción con estos navegadores, el código de estado 302 debe ser competente, porque la forma en que la mayoría de los navegadores manejan la respuesta 302 es exactamente lo que la especificación anterior requiere que el cliente maneje la respuesta 303.
304Si el cliente ha enviado una solicitud GET condicional y la solicitud ha sido permitida, y el contenido del documento (desde la última visita o según las condiciones solicitadas) no ha cambiado, el servidor debería devolver este código de estado. La respuesta 304 prohíbe la inclusión del cuerpo del 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: Date, a menos que este servidor no tenga reloj. Si el servidor sin reloj también cumple con estas reglas, el servidor proxy y el cliente pueden agregar el campo Date al encabezado de respuesta recibido (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 devolver 200 respuestas. Expires,Cache-Control y/o Vary, si su valor puede ser diferente del valor correspondiente a otras respuestas de la misma variable.Si esta solicitud de respuesta utiliza una verificación de caché fuerte, entonces esta respuesta no debe incluir otros cabezales de entidad; de lo contrario (por ejemplo, una solicitud GET condicional utiliza la verificación de caché débil), esta respuesta prohíbe la inclusión de otros cabezales de entidad; esto evita la inconsistencia entre el contenido de la entidad almacenado en caché y la información actualizada del encabezado de la entidad. Si una respuesta 304 indica que una entidad actualmente no está almacenada en caché, entonces el sistema de caché debe ignorar esta respuesta y enviar solicitudes repetidas que no contengan restricciones. Si se recibe una respuesta 304 que requiere la actualización de una entrada de caché, el sistema de caché debe actualizar la entrada completa para reflejar los valores de todos los campos actualizados en la respuesta.
305Los recursos solicitados deben ser accesibles a través del agente especificado. La información del URI del agente especificado se dará en el dominio de ubicación, y el destinatario debe enviar repetidamente una solicitud separada a través del cual se puede acceder al recurso correspondiente. Solo el servidor original puede establecer una respuesta 305. Nota: No hay una respuesta explícita 305 en RFC 2068 para redirigir una solicitud separada y solo puede ser establecida por el servidor original. Ignorar estas restricciones puede tener graves consecuencias para la seguridad.
306En la última versión de la especificación, el código de estado 306 ya no se usa.
307El recurso solicitado ahora responde temporalmente a la solicitud desde un URI diferente. Dado que dicha redirección es temporal, el cliente debe continuar enviando solicitudes posteriores a la dirección original. Esta respuesta solo se puede almacenar en caché si se especifica en Cache-Control o Expires. El nuevo URI temporal debe ser devuelto en el dominio Location de la respuesta. A menos que se trate de una solicitud HEAD, la entidad que responde debe incluir 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 el usuario pueda comprender y emitir una solicitud de acceso al nuevo URI. Si no se trata de una solicitud GET o HEAD, entonces el navegador prohíbe la redirección automática a menos que sea confirmada por el usuario, ya que las condiciones de la solicitud pueden cambiar.
4001. 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. El parámetro de solicitud es incorrecto.
401La solicitud actual requiere autenticación del usuario. La respuesta debe incluir un encabezado WWW-Authenticate aplicable al recurso solicitado para solicitar la información del usuario. El cliente puede reenviar repetidamente una solicitud que incluya el encabezado Authorization adecuado. Si la solicitud actual ya incluye una credencial de autorización, entonces una respuesta 401 indica que la autenticación del servidor ha rechazado dichas credenciales. Si la respuesta 401 incluye la misma solicitud de autenticación que la respuesta anterior y el navegador ya ha intentado la autenticación al menos una vez, el navegador debe mostrar al usuario la entidad incluida en la respuesta, ya que esta entidad puede contener información de diagnóstico relevante. Véase el RFC 2617.
402El código de estado está reservado para posibles necesidades futuras.
403El servidor ha entendido la solicitud, pero se niega a ejecutarlo. A diferencia de la respuesta 401, la autenticación no proporciona ninguna ayuda y esta solicitud no debe enviarse repetidamente. Si no se trata de una solicitud HEAD y el servidor desea poder explicar por qué no se puede ejecutar la solicitud, entonces el motivo del rechazo debe describirse dentro de la entidad. Por supuesto, el servidor también puede devolver una respuesta 404 si no desea que el cliente obtenga ninguna información.
404La solicitud falla y el recurso deseado no se encuentra en el servidor. No hay información que le diga al usuario si esta situación es temporal o permanente. Si el servidor conoce la situación, se debe usar el código de estado 410 para informar que el recurso antiguo no está disponible permanentemente debido a algunos problemas internos del mecanismo de configuración, y que no hay ninguna dirección que pueda redireccionarse. 404 Este código de estado se usa ampliamente cuando el servidor no quiere revelar exactamente por qué se rechaza la solicitud o no hay otra respuesta adecuada disponible.
405El 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 Allow para representar una lista de métodos de solicitud que el recurso actual puede aceptar. En vista de PUT, el método DELETE escribirá los recursos en el servidor, por lo que la mayoría de los servidores web no admiten o no permiten el método de solicitud anterior en la configuración predeterminada, y se devolverá un error 405 para tales solicitudes.
406El atributo de contenido del recurso solicitado no puede cumplir las condiciones en el encabezado de la solicitud y, por lo tanto, no puede generar una entidad de respuesta. A menos que se trate de una solicitud HEAD, la respuesta debe devolver una entidad que contenga una lista de características de entidad y direcciones entre las que el usuario o el navegador puede seleccionar la más adecuada. El formato de la entidad está determinado por el tipo de medio definido en el encabezado Content-Type. El navegador puede tomar la mejor decisión según el formato y sus propias capacidades. Sin embargo, la especificación no define ningún criterio para tal selección automática.
407Similar a la respuesta 401, excepto que el cliente debe autenticarse en el servidor proxy. El servidor proxy debe devolver un Proxy-Authenticate para realizar la consulta de identidad. El cliente puede devolver un encabezado de Proxy-Authorization para la verificación. Véase RFC 2617.
408Tiempo de espera de la solicitud agotado. El cliente no completó el envío de una solicitud dentro del tiempo de espera previsto por el servidor. El cliente puede volver a enviar esta solicitud en cualquier momento sin necesidad de realizar ningún cambio.
409La solicitud no se puede completar debido a un conflicto con el estado actual del recurso solicitado. Este código solo se puede usar en situaciones en las que 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 la fuente del conflicto. Las colisiones generalmente ocurren en el procesamiento de solicitudes de PUT. Por ejemplo, en un entorno que utiliza la verificación de la versión, la información de la versión adjunta a una solicitud de modificación de un recurso específico enviada por un PUT entra en conflicto con una solicitud anterior (de terceros), y el servidor debe devolver un error 409 en este momento. Informe al usuario que la solicitud no se puede completar. En este momento, es probable que la entidad de respuesta incluya una comparación de diferencias entre las dos versiones en conflicto para que el usuario vuelva a enviar la nueva versión después de la compilación.
410El recurso solicitado ya no está disponible en el servidor, y no hay ninguna dirección de reenvío conocida. Esta situación debe considerarse permanente. Si es posible, el cliente que disponga de una función de edición de enlaces debería, tras obtener el consentimiento del usuario, eliminar todas las referencias que apunten a esta dirección. Si el servidor no sabe o no puede determinar si esta situación es permanente, entonces debe utilizar el código de estado 404. A menos que se indique lo contrario, esta respuesta puede ser almacenada en caché. El propósito principal de la respuesta 410 es ayudar a los administradores de sitios web a mantener su sitio, informando a los usuarios de que el recurso ya no está disponible y que el propietario del servidor desea que se eliminen también todos los enlaces externos que apunten a dicho recurso. Este tipo de incidentes son muy comunes en servicios con tiempo limitado o servicios de valor añadido. Del mismo modo, la respuesta 410 también se utiliza para informar al cliente de que, en el sitio del servidor actual, un recurso que anteriormente pertenecía a una determinada persona ya no está disponible. Desde luego, la decisión de marcar todos los recursos permanentemente no disponibles con el código de estado «410 Gone», así como el período durante el cual mantener dicha marca, depende por completo del propietario del servidor.
411El servidor se niega a aceptar la solicitud sin definir el encabezado Content-Length. Después de agregar un encabezado Content-Length válido que indica la longitud del cuerpo del mensaje de solicitud, el cliente puede volver a enviar la solicitud.
412Cuando el servidor verifica que los requisitos previos se dan en el campo de encabezado de la solicitud, uno o más de ellos no se cumplen. Este código de estado permite al cliente establecer condiciones previas en la metainformación solicitada (datos de campo de encabezado de solicitud) cuando obtiene el recurso, evitando así que el método de solicitud se aplique a un recurso distinto del contenido deseado.
413El servidor se niega a procesar la solicitud actual porque el tamaño de los datos del cuerpo de la solicitud supera el límite 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 siga enviando esta solicitud. Si esta situación es temporal, el servidor debe devolver un encabezado de respuesta Retry-After para indicar al cliente después de cuánto tiempo puede volver a intentarlo.
414La longitud del URI solicitado supera la que el servidor puede procesar, por lo que el servidor se niega a atender la solicitud. Esto es relativamente poco común. Los casos más habituales incluyen: un formulario que debería haber utilizado el método POST se envía mediante el método GET, lo que provoca que la cadena de consulta (Query String) sea excesivamente larga. «Agujero negro» de URI de redirección: por ejemplo, cada redirección incorpora la URI anterior como parte de la nueva URI, lo que provoca que, tras varias redirecciones, la URI se vuelva excesivamente larga. El cliente está intentando aprovechar una vulnerabilidad de seguridad presente en ciertos servidores para atacarlos. Este tipo de servidores utiliza un búfer de longitud fija para leer o procesar la URI de las solicitudes. Cuando los parámetros que siguen a la instrucción GET superan un determinado valor, puede producirse un desbordamiento del búfer, lo que podría conducir a la ejecución de código arbitrario [1]. Los servidores que no presentan este tipo de vulnerabilidad deben devolver el código de estado 414.
415Para el método de solicitud actual y el recurso solicitado, la entidad enviada en la solicitud no es el formato que se admite en el servidor, por lo que la solicitud es rechazada.
416Si el encabezado de solicitud de Range está incluido en la solicitud, y cualquier rango de datos especificado en Range no coincide con el rango disponible del recurso actual, y el encabezado de solicitud de Range no está definido en la solicitud, entonces el servidor debe devolver el código de estado 416. Si Range usa un rango de bytes, entonces este caso significa que la ubicación del primer byte de todos los rangos de datos especificados por la solicitud excede la longitud del recurso actual. El servidor también debe incluir un encabezado de entidad Content-Range mientras devuelve el código de estado 416 para indicar la longitud del recurso actual. Esta respuesta también se ha prohibido el uso de multipart/byteranges como su Content-Type.
417El contenido esperado especificado en el encabezado de solicitud Expect no puede ser satisfecho por el servidor, o el servidor es un servidor proxy que tiene evidencia obvia de que el contenido de Expect no puede ser satisfecho en el siguiente nodo de la ruta actual.
421El número de conexiones al servidor desde la dirección IP donde se encuentra el cliente actual excede el rango máximo de licencias del servidor. En general, la dirección IP aquí se refiere a la dirección de cliente que se ve 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 implicar a más de un usuario final.
422El número de conexiones al servidor desde la dirección IP donde se encuentra el cliente actual excede el rango máximo de licencias del servidor. En general, la dirección IP aquí se refiere a la dirección de cliente que se ve 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 implicar a más de un usuario final.
422La solicitud tiene el formato correcto, pero no puede responder debido a errores semánticos. (RFC 4918 WebDAV)423 Locked El recurso actual está bloqueado. (RFC 4918 WebDAV)
424La solicitud actual falla debido a un error en una solicitud anterior, como PROPPATCH. (RFC 4918 WebDAV)
425Está definido en el borrador de Colecciones Avanzadas de WebDAV, pero no aparece en el Protocolo de Conjuntos Ordenados de WebDAV (RFC 3658).
426El cliente debe cambiar a TLS/1.0. (RFC 2817)
449Extendido por Microsoft, significa que la solicitud debe volver a intentarlo después de realizar las operaciones apropiadas.
500El servidor se encontró con una situación inesperada que hizo que no pudiera completar el procesamiento de la solicitud. En términos generales, este problema ocurre cuando el código del servidor es incorrecto.
501El servidor no admite ninguna de las funciones necesarias para la solicitud actual. Cuando el servidor no reconoce el método solicitado y no puede admitir su solicitud a ningún recurso.
502Cuando un servidor que trabaja como puerta de enlace o proxy intenta ejecutar una solicitud, recibe una respuesta no válida del servidor ascendente.
503El servidor actualmente no puede procesar solicitudes debido al mantenimiento temporal o la sobrecarga del servidor. Esta condición es temporal y se reanudará después de algún tiempo. Si se puede esperar el tiempo de retardo, la respuesta puede incluir un cabezal Retry-After para indicar este tiempo de retardo. Si esta información de Retry-After no se proporciona, entonces el cliente debe procesarla de manera que maneje la respuesta 500. Nota: La presencia del código de estado 503 no significa que el servidor tenga que usarlo cuando está sobrecargado. Algunos servidores simplemente desean rechazar la conexión del cliente.
504Cuando un servidor que trabaja como una puerta de enlace o un proxy intenta ejecutar una solicitud, no recibe una respuesta de un servidor ascendente (un servidor identificado por el URI, por ejemplo, HTTP, FTP, LDAP) o un servidor secundario (por ejemplo, DNS) a tiempo. Nota: Algunos servidores proxy devuelven 400 o 500 errores cuando se espera la consulta de DNS
505El servidor no admite o rechaza 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 una entidad que describa por qué no se admiten las versiones y qué protocolos admite el servidor.
506Ampliado por el "Acuerdo de negociación de contenido transparente" (RFC 2295), significa que el servidor tiene un error de configuración interno: el recurso variable de negociación solicitado está configurado para usarse en la negociación de contenido transparente, por lo que no es un enfoque adecuado en un procesamiento de negociación.
507El servidor no puede almacenar el contenido necesario para completar la solicitud. Esta situación se considera temporal. WebDAV(RFC 4918)
509El servidor alcanza el límite de ancho de banda. Este no es un código de estado oficial, pero todavía se usa ampliamente.
510La estrategia necesaria para obtener recursos no está satisfecha. (RFC 2774)
Su huella:

Caja de herramientas iToolifyNavegación

Enlace de amistad:iCMS