Lista de códigos de estado HTTP ? Códigos de error HTTP explicados

Cada vez que se ejecuta una tarea en un dispositivo supervisado, el servidor de destino devuelve códigos de estado HTTP para indicar el estado de la respuesta del servidor.

Estos códigos de estado HTTP, o códigos de error de red,aparecerán en los resultados de una sesión de supervisión, así como en las notificaciones de alerta. Estos códigos de estado son mantenidos por internet Assigned Numbers Authority (IANA) y la lista más reciente de códigos se puede encontrar aquí.

Con Filtros puede eliminar resultados con códigos de estado específicos de sus tareas, alertas e informes. Haga clic en los documentos de referencia RFC en la lista siguiente para obtener detalles completos de los códigos de estado.

 

¿Quét es el protocolo HTTP?

Cada vez que un usuario visita un sitio web, está haciendo una solicitud desde su navegador/cliente a un servidor que responde con los recursos que solicitó. Todas estas solicitudes siguen el estándar HTTP (Protocolo de transferencia de hipertexto). El HTTP protocolo, que técnicamente forma parte de la capa de aplicación dentro de la suite de protocolo de Internet, es sólo una muchos protocolosbajo el conjunto IP. El El protocolo HTTP es la columna vertebral de Internet utilizada para la comunicación y el envío de datos entre clientes y servidores. Algunos de los otros protocolos de Internet más comunes muchos han encontrado incluyen lo siguiente:

 

Protocolos de capa de aplicación

el aplicación laTEr especifica los protocolos y métodos de interfaz utilizados por clientes y servidores. eso Es la capa waquí el interacción entre persona y computadora ocurre Und Información se puede enviar de ida y vuelta desde un servidor a través de un cliente/navegador e interpretado y mostrado para los usuarios.

• DNS: El protocolo DNS(Sistema de nombres de dominio) convierte losnombres de dominio en direcciones IP legibles por el explorador para que se puedan cargar los recursos.
• FTP: El protocolo FTP (Protocolode transferencia de archivos) se utiliza para transferir archivos entre un navegador y un servidor within a computer network.
• SMTP: El protocolo SMTP (Protocolosimple de transferencia decorreo) se utiliza para enviar unnd receive correos electrónicos entre remitentes y receptores en una red.
• TLS/SSL: El protocolo SSL (SecureSockets Layer) quedó oficialmente en desuso en 2015. TLS(Transport Layer Security) se introdujo en su lugar para proporcionar una forma segura de comunicarse a través de una red.
• IMAP: El protocolo IMAP (Protocolo de acceso a mensajes de Internet) se utiliza para administrar y recibir mensajes de un servidor de correo electrónico. A diferencia de SMTP, no puede utilizar el protocolo IMAP para enviar mensajes de correo electrónico.
• POP: El protocolo POP (Post Office Protocol) es como IMAP, pero la diferencia es que el protocolo POP permite al usuario recibir mensajes de un servidor de correo electrónico, pero el mensaje se elimina del servidor de correo electrónico. El protocolo IMAP puede sincronizar mensajes entre varios dispositivos. Realmente depende de cómo desea que los usuarios accedan a sus correos electrónicos.
• SIP: Tél SIP(Protocolode inicio de sesión) protocolo es un protocolo de señalización que se utiliza en la voz en tiempo real, aplicaciones de vídeo y mensajería. SIP es el protocolo que se utiliza para habilitar y deploy VoIP (Voice Over InternetProtocol) Servicios. Sip También se utiliza junto con otros protocolos, como SDP(Session Description Protocol), UDP, TCP y TLS para transportar datos y medios de sesión.

 

Protocolos de capa de transporte

La capa de transporte gestiona la transmisión de datos,que también incluye el TCP y UDP protocolos,y garantizar que los datos se envíen y reciban correctamente y con prontitud.

• Tcp: El protocolo TCP (Protocolo de control de transporte) se utiliza para garantizar que las transmisiones entre un cliente y un servidor sean seguras y que el se procesó toda la comunicación. Por ejemplo, Cuando un servidor devuelve un archivo debido a una solicitud de cliente, la capa HTTP se comunicará con la capa de transporte para configurar y enviar el archivo solicitado. El protocolo TCP gestiona el proceso de montaje y envío (y a veces volver a enviar, si es necesario) los paquetes de datos y garantiza que todos los paquetes han sido enviados y entregados.
• UDP: El protocolo UDP (User Datagram Protocol) permite a las aplicaciones enviar mensajes, llamados datagramas, a otros hosts de una red.

 

Protocolos de capa de Internet

La capa de Internet, también llamada capa de red, tiene la tarea de enviar y volver a montar los packets de red de la manera más eficiente utilizando direcciones de red/dirección IP para enviar paquetes a su destino.

• IP: El protocolo IP (Protocolo de Internet) protocol, junto con elprotocolo TCP, es un conjunto de requisitos que definen cómo se envían los datos a través de Internet.
• ICMP: El protocolo ICMP (Internet Control Message Protocol) es un protocolo de red que permite a los dispositivos de red, como enrutadores,ayudar a diagnosticar problemas de comunicación. El protocolo ICMP no se ocupa del intercambio de datos,más bien su propósito es asegurarsedeque si los datos están llegando al destino previsto.

 

Protocolos de capa de enlace

La capa de enlace es elgrupo de métodos de comunicación que gestiona la transmisión de datos entre dispositivos físicos y una red.

• ARP: El protocolo/procedimiento ARP (Address Resolution Protocol)para asignar direcciones de red IP a una dirección de un dispositivo de hardware físico, también conocido como dirección MAC.
• MAC: El protocolo MAC (Control de acceso medio) da a los dispositivos de hardware su número de identificación único. Proporciona una manera para que las redes consonct y comunicarse con los dispositivos.
• Wi-Fi: El protocolo Wi-Fi (Wireless Fidelity), que es uno de los protocolos en los que todos confiamos para la vida cotidiana, es un grupo de protocolos de red inalámbrica que se utiliza para conectarse al acceso a Internet y LAN (Redes de área local).

 

¿Qué son los códigos de estado y por qué son importantes?

Incluso hay extensiones Dela Protocolo HTTP, que incluyedes HTTPS (Protocolo de transferencia de hipertexto seguro) y WebDAV (Web-based Distributed Authoring and Versioning),quediscutiremos más dentro de los códigos de estado HTTP Abajo. Cuando un cliente realiza una solicitud al servidor, los códigos de estado le permiten saber si la solicitud se realizó correctamente, ha fallado o algo diferente. Los códigos de estado son mantenidos por el Internet Assigned Numbers Authority, o IANA, e incluye códigos de estado del Grupo de Trabajo de Ingeniería de Internet (IETF) y de Internet Society (ISOC). Según lo definido por la IANA OrganizaciónTaquí hay cinco clasificaciones de bacalao de estado HTTPes:

1xx: Informativo – Solicitud recibida, proceso continuo
2xx: Success – La acción fue recibida, entendida y aceptada con éxito
3xx: Redirección – Se deben tomar medidas adicionales para completar la solicitud
4xx: Error de cliente: la solicitud contiene una sintaxis incorrecta o no se puede cumplir
5xx: Error de servidor – El servidor no pudo cumplir con una solicitud aparentemente válida

Individuos e ingenieros regularmente Proponer nuevos códigos de estado a través de Solicitudes de Comments (RFC), y el IETF revisará, adoptar, y Retirarse Estado Códigos según sea necesario.

 

Códigos de estado HTTP explicados

La siguiente información proporciona una visión general de todos los códigos de estado HTTP más comunes, así como los códigos de estado HTTP que la mayoría de la gente rara vez nunca ve o incluso sabe que existen. Como mencionamos, muchos códigos de respuesta nunca se ven por los usuarios,ya que sólo se pueden ver dentro de la red.

El primer dígito del código de estado identifica la clase; sin embargo, los dos segundos dígitos no desempeñan ningún papel en la definición adicional del código de estado a un tipo específico de mensaje/respuesta. Dentro de estos grupos de clasificación, puede haber varios códigos de estado y algunos grupos tienen más códigos de estado que otros. Y aunque oficialmente hay más de 60 códigos de estado únicos, la mayoría de la gente regularmente sólo encontrarse con un puñado o dos con el tiempo.

La mayoría de estos códigos de estado se interpretan y procesan en segundo plano. También verá que hay grupos de códigos etiquetados como “Sin asignar.” Si bien la mayoría de los códigos de estado que vemos hoy en día han sido estandarizados y han no cambiado con el tiempo, estos números sin asignar dejan espacio para crear códigos de estado adicionales según sea necesario. Además, aunque algunos de los códigos de usuario no asignados no forman parte anteriormente del estándar HTTP (Protocolo de transferencia de hipertexto), hay empresas que los utilizan como respuesta personalizada del servidor para los usuarios, lo que permite a las empresas solucionar mejor los problemas que los usuarios pueden estar experimentando. Haga clic en los enlaces del documento de referencia RFC en la lista siguiente para obtener detalles completos del código de estado HTTP específico.

 

Una lista completa y una descripción general de los códigos de estado HTTP

 

1xx Código de estados: Informativo

El 1Xx-los códigos de estado HTTP de nivel indican a los usuarios que la solicitud de que Ellos have hecho ha sido recibido, pero todavía se está procesando. Los códigos de estado 1xx No necesariamente significa que hay un problema, que Yos sólo allí para dejar que algo todavía está en el proceso de completar. Incluido en este grupo son sólo un puñado de 1Xx códigos que los usuarios pueden encontrar y necesitan ser conscientes de.

 

100: Continuar

Status código 100 Continuar le indica que una parte de la solicitud se ha recibido sin ningún problema. En este punto todo es Ok, pero sigue siendo en proceso. Si el parte restante de la solicitud no es rechazada, el servicioR enviará una respuesta final una vez que la solicitud ha sido completaEd. Si los encabezados HTTP se han rechazado, esto garantiza que el cliente No enviar una solicitud para el cuerpo. Sin embargo, si la solicitud lo hizo no contain un campo de encabezado, entonces el navegador simplemente ignorará el response. See RFC7231, Sección 6.2.1 para más información.

101: Cambio de protocolos

Ha habido muchos protocolos HTTP creados desde los humildes comienzos de Internet. La primera versión documentada del protocolo HTTP fue HTTP 0.9. La iteración actual es HTTP 2.0 o HTTP/2. Código de estado 101 Los protocolos de conmutación indican que el servidor acepta la solicitud del cliente de cambiar a un protocolo HTTP diferente a través del campo Encabezado de actualización. Cuando un navegador realiza una solicitud de una página, puede recibir el Código de estado HTTP 101 y luego el encabezado Upgrade, whiCh Indica el servidor está cambiando a una versión HTTP diferente. Por último, suponiendoque el servidor estará de acuerdo en cambiar de protocolo sólo cuando seabeneficioso, como actualizar/cambiar a un protocolo más reciente frente a uno más antiguo. See RFC7231, Sección 6.2.2 para obtener más información.

102: Procesamiento

Un estado coda 102 El procesamiento solo se utiliza con WebDAV (Web Distributed Authoring and Versioning). La mayoría de las páginas son de sololectura. WebDAV es una extensión del HTTP protocolo que ofrece a los clientes la capacidad deeditar contenido de forma remota y transferir archivos. el Webdav protocolo fue creado para dar a los usuarios la capacidad de colaborare en archivos con otros, Como Dropbox o Google Drive. El código de estado 102 es unN código de respuesta provisional, indicando al cliente que el servidor ha aceptado la solicitud completa, pero no ha completado la solicitud. Este código de estado HTTP solo se envía por el servidor Si Un solicitud está tardando más de 20 segundos. Ver RFC2518, Sección 10.2 para obtener más información.

103: Consejos tempranos

Códigos de estado 103 Sugerencias tempranas se encuentra actualmente en la evaluación/fase experimental. Este código de estado se utilizaría al precargar contenido/recursos externos. El protocolo HTTP/2 permite que el contenido se empuje para acelerar la entrega, para que los desarrolladores web pudieran empujar contenido específico mientras esperaban a que otros recursos externos se cargara. Esto es beneficioso desde la perspectiva del usuario final, ya que minimiza el tiempo de carga percibido. Tsu código de respuesta HTTP Indicar a un navegador que el servidor es va a enviar una respuesta final,junto con los campos de encabezado incluidos en la respuesta. See RFC8297, Sección 2 para más información

 

104-199: Sin asignar

Los códigos de estado 104 a 199 están actualmente sin asignar.

 

2xx Código de estado: Correcto

Los códigos de estado HTTP de nivel 2xx indicar que la solicitud del cliente del servidor fue correcta yprocesada. A diferencia de los códigos de estado 4xx, los códigos de estado 2xx son lo que desea obtener. Al igual que los códigos de estado 1xx, los códigos de estado 2xx se procesan en segundo plano y rara vezson vistos por losusuarios, a menos que estén utilizando herramientas de desarrollador o SEO para ver todas las respuestas HTTP de una página.

 

200: OK

Uno de los códigos de estado HTTP más utilizados, el código de estado 200 OK se utiliza para indicar que se recibió,procesó una solicitudy se realizó correctamente. Sin embargo, dependiendo del método de solicitud utilizado (GET, HEAD, POST, PUT, DELETE, OPTIONS, TRACE). Por ejemplo, si la solicitud es una solicitud GET, la respuesta incluirá el recurso. Si Es cualquiera de los otros rebúsquedas, la respuesta incluirá el resultado de las acciones. el 200 estatus código es uno de más de 10 códigos de respuesta más que también se puede almacenar en caché, lo que significa que se puede guardar y recuperado a través de la cliente, con el fin de no tener que hacer otra solicitud al servidor en el futuro. See RFC7231, Sección 6.3.1 para más información.

201: Creado

Un código de estado 201 Creado es como un código de estado 200 OK, sin embargo, un código de estado 201 significa que una solicitud se procesó correctamente y devolvió,o creó, un recurso o resources en el proceso. Un El código de estado 201 se utiliza normalmente para las solicitudes PUT. Por ejemplo, when se utiliza una solicitud PUT, se crea un nuevorecurso en la URL especificado en la solicitud. Si hay un código de estado 201 en una solicitud POST, significa que se creó un recurso en un punto de conexión o ubicación de API diferente. See RFC7231, Sección 6.3.2 para más información.

202: Aceptado

el 202 Aceptado Estado code significa que el servidor ha recibió una solicitud de procesamiento, y Yoha sido aceptado, pero la solicitud ha No se ha completado. También No significa que la solicitud será finalmente aceptada, ya que dependerá de cuándo tenga lugar el procesamiento real. Este tipo de solicitud se ve normalmente en las API donde se ejecuta un proceso por lotes una vez al día. Desde allí Es no hay manera de que HTTP se comunique después de un solicitud ha tenido éxito o la conexión del usuario se ha cerrado, una API podría enviar un correo electrónico a un usuario notifying Ellos que el proceso ha tenido éxito. See RFC7231, Section 6.3.3 para más información.

203: Información no autorizada

El código de estado 203 De información no autorizada se utiliza normalmente en un Proxy HTTP o tercero. El proxy, sentado entre el cliente y el servidor puede cambiar las respuestas antes de llegar al cliente. Para Indicar que algo fue cambiado durante el se utiliza un código de estado 203. Sin embargo, el inconveniente de este método es que eso Yos no es posible saber cuál era el código de estado original si un proxy cambió algo en la respuesta. Una solución sugerida es utilizar un encabezado de advertencia junto con un Estado 214 Código que se utiliza Para indicae que hubo un cambio o modificación en la response. Usando el wel encabezado de arning permite que el código de estado original pasado a través deh. See RFC7231, Section 6.3.4 para obtener más información.

204: Sin contenido

Un código de estado de 204 Sin contenido Indica que la respuesta ha sido entregada con éxito por el servidor y cumplida y no más content debe ser enviado en el cuerpo de la respuesta. Como ejemplo, si la solicitud se envía en el formulario en una página, una vez que el response es enviado, el cliente/navegador no se supone que cambie la vista, lo que significa que la forma debe No ser renovado o directo Usuarios a un nuevo page. e. No contenido adicional debe ser reemplazado o aparecer en términos de la perspectiva del usuario. See RFC7231, Section 6.3.5 para obtener más información.

205: Restablecer contenido

Al igual que el 204 No Content status code, un código de estado 205 Restablecer contenido indica que el servidor ha enviado la solicitud correctamente y requiere que el agente de usuario actualice/restablezca la vista a su oiestado ginal. Si usamos el ejemplo de un formulario en una página, una vez que el usuario completa y enviars el formulario,el cliente / navegador debe borrar el formulario de nuevo a su estado original para que un usuario puede tomar furtsu acción. Un El código de estado 205 supone que no se proporcionará ningún otro contenido. See RFC7231, Sección 6.3.6 para obtener más información.

206: Contenido parcial

A 206 El código de estado de Contenido Parcial se puede utilizar para una variedad de solicitudes y, por lo general, Indica que el servidor ha cumplido una Parcial solicitar un recurso. Por ejemplo, si un cliente solo está buscando un Porción, o rango, De Un Específico Recursos o página. Otro ejemplo de dónde Estado 206 código se utiliza es en video. Un cliente solo puede cargar vídeo en trozos para no tener que esperar a que el vídeo se almacena en búfer o cargar, ayudando a evitar una experiencia de usuario negativa en la que un usuario tendría que esperar más tiempo antes de que se reproduzca el vídeo. Esta es la mejor práctica normal entre el reproductor de vídeo HTTPs para evitar el ancho de banda y los problemas de latencia percibidos. See RFC7233, Sección 4.1 para obtener más información.

207: Multi-Estado

el 207 Multi-Estado Estado code Proporciona estado para múltiples procesos independientes y utilizado por los servidores WebDAV. El mensaje/respuesta predeterminado es un mensaje de texto/XML. eso Indica que se han llevado a cabo varias operaciones y que el estado de cada operación se puede ver en el cuerpo de la response. Los códigos de estado pueden variar entre cualquiera de las cinco categorías. Los códigos de respuesta variarán en función del número de sub-solicitudes. A diferencia de otras 200 estatuass códigos, un código de estado 207 no confirmar que el proceso fue exitoso. El cliente necesita ver el cuerpo de cada solicitud para determinar si tuvo éxito o no. See RFC4918, Sección 11.1 para obtener más información.

208: Ya reportado

el 208 Ya reportado Estado código es otro código de estado utilizado dentro de la extensión WebDAV. Como el Estado 207 código, que permite a un cliente/navegador Indicar al servidor que un ya se procesó. Cuando un cliente solicita recursos, puede ser posible que una respuesta incluya recursos duplicados, lo que significaría que los mismos recursos se enviarían varias veces, lo que es redundante. el La respuesta de estado 208 evita la posibilidad de procesar y repetir la misma respuesta. 208 código de estado Respuestas sólo aparecerá en el cuerpo de la respuesta y nunca como una respuesta HTTPreal. See RFC5842, Sección 7.1 para obtener más información.

209-225: Sin asignar

Los códigos de estado 209 a 225 no están asignados actualmente.

226: IM Usado

Un código de estado 226 IM (Instance Manipulations) Used se utiliza para indicar que un servidor ha completado una solicitud GET para un recurso,pero la respuesta es la representación de una o varias manipulaciones de instancia que se han aplicado a la instancia actual. Dentro del protocolo HTTP hay una extensión llamada codificación Delta en HTTP que se soporta en el lado del servidor. Si esto es implemen caso de que el cliente pueda solicitar cambios en la versión almacenada en caché y el servidor enviará los cambios en lugar de volveraenviar el nuevoorigen completo. Para poder implementar esta característica, la solicitud cliente/navegador debe especifique qué tipo de mensajería instantánea admite. Si el servidor también admite esta característica, responderá con el 226 código de estado y los cambios. Si un Se devuelve el código de estado 200, lo que indica que no se admite la característica. See RFC3229, Sección 10.4.1 para obtener más información.

227-299: Sin asignar

Los códigos de estado 227 a 299 no están asignados actualmente.

 

3xx: Redirección

Los códigos de estado 3xx se utilizan en casos de redirección de URL. Los sitios web siempre están cambiando y evolucionando, por lo que puede haber momentos enlos que los mar keters necesitan dirigir a los usuarios a una página actualizada o diferente. Las redirecciones ayudan a aliviar a los usuarios de tener que buscar lo que están buscando y mantener su clasificación en motores debúsqueda. Las acciones de redirección pueden ser llevadas a cabo por el navegador de forma automática o pueden requerir la interacción adicional de los usuarios. Los códigos de estado HTTP 3xx son vitales para SEO (Search Engine Optimization) y la experiencia del usuario, así como decirle a los motores de búsqueda qué contenido desea que rastreen e indexen. Yof no implementado correctamente, los usuarios pueden ser dirigidos a una ubicación no deseada,lo que podría resultar en un código de estado4xx y podría afectar a las puntuaciones de calidad SEO.

 

300: Múltiples opciones

El código de estado 300 Multiple Choices indica que un resource se ha movido y puede redirigir a varias ubicaciones. En este caso, el usuario debe decidir qué recurso utilizar. El servidor puede Indicar una elección preferida y que debería ser Indicado en el encabezado Campo donde el agente de usuario podría redirigir a la opción preferida automáticamente. En uso práctico, tsu código de estado rara vez se utiliza, ya que no hay una manera estandarizada de elegir entre múltiples respuestas. See RFC7231, Sección 6.4.1 para más información.

301: Se movió permanentemente

Se utiliza un código de estado 301 Moved Permanently para indicar que un recurso de destino se ha movido a una ubicaciónpermanente. El código de estado 301 indica al navegador/cliente que utilice esta nueva ubicación o URL en el encabezado. Junto con el 301 Estado código, la nueva URL será Dado en la respuesta así como actualizar cualquier URL en el Anterior Ubicación(s), junto con la actualización a la nueva URL. See RFC7231, Sección 6.4.2 para más información.

302: Encontrado

Un código de estado 302 Encontrado indica a un cliente/navegador que un recurso al que están accediendo está temporalmente Situado en una ubicación diferente. A diferencia del código de estado 301, un El código de estado 302 indica un movimiento temporal, por lo que el cliente no debe Automáticamente actualizar su Enlaces a la nueva ubicación, como de nuevo, Yos para ser temporal. Un ejemplo de dónde 302 estatus código debe utilizarse si hay Son Múltiples Url, pero podría servirse en diferentes idiomas. Un usuario puede llegar a una URL específica, pero el cliente puede redirigirlos automáticamente a la página adecuada basado en la configuración de su navegador y utilizar este on visitas posteriores. Es is señaló que en algunos casos, los navegadores pueden cambiar una solicitud de POST a GET. En el caso de que esta acción sea no es favorable, se debe utilizarun código de estado 307 . See RFC7231, Sección 6.4.3 para obtener más información.

303: Véase Otro

Un código de estado 303 Consulte Otro indica que un servidor redirigirá el cliente/navegador a otro recurso. El recurso será indica como URL el campo de encabezado. A diferencia de los códigos de estado 301 y 302, No significa que un recurso tiene temporaRio se mueve permanentemente,s intención es especificar la Url a donde la respuesta a la specifYoC solicitud puede ser Encontrado a través de una solicitud GET. 303 códigos de estado deben No en caché, sin embargo, la respuesta a la subsiguiente solicitud puede ser almacenada en caché. Un uso típico de la 303 estatus código sería para asegurar a los usuarios do no reenviar accidentalmente datos de formulario a través de una solicitud POST. Deben dirigirse a una nueva página. Si no es así, pueden hacer clic sin saberlo el botón Atrás en su navegador,que puede pedirles que vuelvan a presentarse de nuevo, lo que lleva a unnecessary duplicaciónde las comunicaciones. See RFC7231, Sección 6.4.4 para obtener más información.

304: No modificado

Un código de estado de 304 No modificado se envía en respuesta a una solicitud GET o HEAD condicional. Los clientes/navegadores pueden enviar una solicitud condicional,como If-Match, If-None-Match, If-Modified-Since, If-Unmodified-Since, o If-Range, preguntando si se ha modificado un recurso específico desde una fecha/hora específica. éste Es solo si el cliente ha accedido, descargado y guardado previamente el recurso. Si ha sido modificado desde la última fecha/hora específica a la que se accedió por última vez, el servidor devolverá un código de estado 200 OK. Si ha No desde esa fecha/hora, el 304 estatus código se envía como la respuesta, Indicando que el recurso guardado debe ser servido ya que ha No Sido Modificado desde la última vez que se accedió a ella. See RFC7232, Sección 4.1 para más información.

305: Usar Proxy

El código de estado 305 Use Proxy sun código de estado en desuso que ya no se utiliza debido a la consideración de seguridad. eso se utilizó para indicate a un cliente que el resource que estaban accediendo debe ser accedido a través de un proxy. Para obtener más información sobre el código de estado 305 Use Proxy, consulte RFC7231, Sección 6.4.5

306: Sin usar

Al igual que el código de estado 305, el estado 306 Sin usar fue originalmente conocido como Switch Proxy. el El código de estado 306 se utilizó en un Especificación. Su intención era ser utilizado como en indicación al cliente de que las siguientes preguntasts a un recurso deben utilizar el proxy que se especificó. Esto se consideró como un problema de seguridad, por lo que ya no se utiliza. Para obtener más información sobre el código de estado no utilizado 306, consulte RFC7231, Sección 6.4.6

307: Redirección temporal

Como el 302 Encontrado redirigir el código de estadoTél 307 Redirección temporal Estado code Indica al cliente/navegador que un recurso o documento está disponible en unTemporal URL y devuelve esa dirección URL. Dado que la redirección es temporal y podría cambiar, el navegador/cliente debe seguir accediendo a la URL actual para subsiguiente Solicitudes. La principal diferencia entre la 302 estatus código y el código 307 estatus código es que el 307 estatus código no permite cambiar las solicitudes de Un Exponer solicitud a un Obtener Petición, por lo que si el cliente solicitó la solicitud POST, se le redirigirá y Iniciar la solicitud POST de nuevo. See RFC7231, Sección 6.4.7

308: Redirección permanente

Un código de estado de redirección permanente 308 es un código de estado almacenable en caché (a menos que se implementen controles de caché) que indica que un recurso de destino se encuentra ahora en una dirección URL permanente y subsequent las solicitudes deben dirigirse a esa URL, así. Además, el cliente debe actualizar cualquier marcadores antiguos a la nueva ubicación. El código de estado 308 es muy similar al código de estado 301, sin embargo, si se envía un código de estado 308, el client tiene que Iniciar y enviar la misma solicitud en la ubicación de destino. Un 301 código de estado no t tienen que hacer esto. La mayoría de los navegadores/clientes cambian la solicitud POST a un req GETuest. See RFC7238, Sección 3 para obtener más información.

 

309-399: Sin asignar

Los códigos de estado 309 a 399 están actualmente sin asignar.

 

4xx: Error del cliente

La clasificación con la mayoría de los códigos de estado HTTP, Los códigos de estado HTTP 4xx no son lo que desea que vean los usuarios. Cualquier código de estado que comience con un 4 significa quehay un problema con el cliente. Los códigos de estado 4xx se generan normalmente si una página se ha eliminado y no se ha redirigido, o si se ha introducido incorrectamente en una URL o enlace. Si los usuarios obtienen un temido código de estado 4xx, eso significa que hay un problema con el cliente/navegador recibiendo información del servidor. Estos son errores que los usuarios verán aparecer en su pantalla y crear una experiencia de usuario negativa,lo que lleva a un poco de frustración y ellos buscando en otro lugar. Si los motores de búsqueda rastrean su sitio y reciben un error 404, por ejemplo, esto se mostrará como un error en el informe. Un pocos errores 404 están bien y los motores de búsqueda no necesariamente ven estos como una cosa negativa,pero un 404 que redirige a un 404 podría impacta negativamente en su SEO. No sólo eso, si la página en cuestión se utiliza para impulsar el tráfico o las ventas, esto podría conducir a la pérdida de ingresos potenciales.

 

400: Mala solicitud

Una solicitud de 400 errores código de estado de error significa que el servidor no puede procesar la solicitud debido a un problema del cliente. Esto podría ser debido a cualquier número de razones, como que un archivo sea demasiado grande, mala sintaxis, una dirección URL no válida, o algún otro problema cautilizado poruna aplicación de terceros, por lo que el código de estado 400 se utiliza a veces como un catch todo el código de estado,incluso si hay un problema en el lado del servidor. Esto puede hacer que la solución de problemas sea 400 estatus código un poco más lento y difícil, sin embargo, junto con el 400 Estado error de código e información de encabezado, tél servidor puede proporcionar Adicional respuesta a lo largo de ingenioh, que se puede mostrar para el usuario para ayudar Identificar el problema y facilitar el proceso de solución de problemas y el diagnóstico del error. See RFC7231, Sección 6.5.1 para más información.

401: No autorizado

Un 401 Error no autorizado el código de estado indica que la solicitud no incluye las credenciales de autenticación adecuadas,la authentication ha falladoo el usuario debe iniciarsesión. El cliente requiere la autenticación del servidor. Los términos autorizados y autenticados a menudo se utilizan indistintamente, pero significan cosas separadas. Un código de estado de 401 es Strictly preocupado con autenticación. En los casos en los que desearía informar a un cliente que no están permitidos En absoluto, a continuación, un código de estado de 403 debe aplicarse. Unde acuerdo con la especificación, el 401 estatus código también debe incluir la WWW-Authenticate encabezado desde el servidor Respuesta, Indicando al cliente qué esquema o método de autenticación el servidor Requires. See RFC7235, Sección 3.1 para más información.

402: Pago requerido

Originalmente creard como parte de una manera de permitir futuros métodosde pagodigitales, el error 402 Pago requerido código de estado está oficialmente reservado para uso futuro, pero utilizó algunos limitados, pero raros, situaciones. Para obtener más información sobre el código de error 402 Payment Required, consulte RFC7231, Sección 6.5.2

403: Prohibido

El 403 El código de estado de error prohibido indica que se ha entendido la solicitud del cliente, pero el servidor no la autorizará,por lo que el clienteno puede acceder a ella. El servidor puede dar a conocer la razón por la que wIIIno autorizar la solicitud dentro de la respuesta, que podría ser debido a varias razones como contraseña incorrecta o nombre de usuario. A diferencia de la 401 estatus código, que requieren autenticación, un 403 estatus código puede Indicar que el cliente realmente no tiene autorización para acceder a esos recursos, por lo que la autenticación en este caso Es No Posible. See RFC7231, Sección 6.5.3 para más información.

404: No encontrado

Uno de los códigos de estado más comunes e infames encontrados por los usuarios y los desarrolladores, el 404 No encontrado Error código de estado Indica que el recurso Obligatorio desde el servidor hace No existen o es not dispuesto a proporcionarlo al cliente. Un 404 estatus code no lo hará Indicar si the falta de proporcionar el recurso es temporal o permanentemente,pero el cliente puede hacer solicitudes de subsequent para acceder a él. En los casos en que se sepa que los recursos han desaparecido permanentemente, el código de estado 410 debe utilizado. Los códigos de estado 404, de forma predeterminada, también se pueden almacenar en caché, a menos que otros controles de caché se coloquenenel lugar. See RFC7231, Sección 6.5.4 para obtener más información.

405: Método no permitido

El código de estado de error 405 Method Not Allowed indica que un recurso específico solicitado por el cliente no es compatible con el servidor. El método 405 no permitido es Como el 403 Paracódigo de estado prohibido, sin embargo, el 403 estatus code Indica que el recurso puede estar disponibleeso Yos sólo que el cliente hace No autorización necesaria para llevar a cabo la solicitud. Junto con el estado Método 405 No permitido, el servidor debe Indicar el appropriate Y Apoyado Métodos para el recurso de destino. Para obtener más información sobre el código de error 405 Method Not Allowed, consulte RFC7231, Sección 6.5.5

406: No aceptable

Al igual que el código de estado de error 405 Method Not Allowed, el código de error 406 Not Acceptable indica que no hay compatibilidad con una solicitud específica. En este caso tél 406 Código de estado no aceptable indica que el servidor entendió la solicitud, pero la respuesta no es apoyado o entendido por el cliente. Un cliente puede solicitar versiones específicas de un recurso en el encabezado, como A-IM o Aceptar el lenguaje, entre otros, pero si el servidor hace No apoyarlo, responde con el código de estado 406 No Aceptable. El servidor puede responder con una lista de recurso adecuado identificadores que el cliente puede elegir De. See RFC7231, Sección 6.5.6 por more Información.

407: Autenticación de proxy requerida

La autenticación de proxy 407 requerida error sel código tatus es Como el 401 Código de estado no autorizado, sin embargo, en el caso de un 407 estatus Código con el fin de utilizar un proxy, el cliente primero debe autenticarse. El proxy debe devolver el método para la autenticación. No es tan común hoy en día debido al aumento de las VPN, actuar como intermediarios entre usuarios/clientes e Internet, permitiendo a los usuarios acceder a los recursos más rápidamente, ya que el contenido Típicamente Caché, y puede Además proporcionar una capa de seguridad y anonimato para los usuarios. Para obtener más información sobre el código de error 407 Proxy Authentication Required, consulte RFC7235, Sección 3.2

408: Tiempo de espera de solicitud

Un código de estado de error de tiempo de espera de solicitud 408 significa que el servidor no recibió una solicitud del cliente en un período de tiempo especificado. Una solicitud retrasada del cliente puede deberse a una variedad de razones, como una conexión lenta o rota. Una vez transcurrido ese tiempo, el servidor envía el estado de tiempo de espera de solicitud 408 y el usuario/cliente puede volver a enviar la solicitud de nuevo. Para obtener más información sobre el código de error de tiempo de espera de solicitud 408, consulte RFC7231, Sección 6.5.7

409: Conflicto

Un conflicto 409 Error código de estado Indica que la solicitud del cliente podría noT debido a un conflicto con el servidor. La solicitud del cliente estaba bien, pero no Fueron problemas en el lado del servidor que impide que se ejecute la solicitud. Un ejemplo de esto podría ser si hubiera una solicitud para que se edite un archivo específico, eliminard, o creado por el usuario, pero esas funcionalidades no están permitidas. Junto con la respuesta 409, el servidor debe devolver instrucciones sobre cómo el usuario puede resolver este problema o indicarpor qué se produce el problema eng. See RFC7231, Sección 6.5.8 para obtener más información.

410: Se ha ido

Al igual que el código de estado de error 404 Not Found que cubrimos anteriormente, elcódigo de estado410 Gone indica que el recurso que el cliente está solicitando se ha eliminado y ya no está disponible en el servidor. No se proporciona más información en términos de redirección de URL o dónde acceder al recurso. Se ha eliminado indefinidamente. Para obtener más información sobre el código de error 410 Gone, consulte RFC7231, Sección 6.5.9

411: Longitud requerida

El código de estado de error 411 Length Required indica que el servidor no permite la solicitud del cliente debido a un cuerpo de solicitud predefinido content length. El cliente puede repetir la solicitud si se especifica un encabezado Content-Length válido en la solicitud de recursos posterior. Para obtener más información sobre el código de error 411 Length Required, consulte RFC7231, Sección 6.5.10

412: Error en la condición previa

Solicitudes condicionales al servidor se permiten como parte del protocolo HTTP. Si la derecha condiciones se cumplen en la solicitud, la solicitud es ejecutada y procesada por el servidor. Un código de estado de error erróneo de condición previa 412 significa que una o varias condiciones en el encabezado de solicitud han fallado. Por ejemplo, esto se puede utilizar en la solicitud GETs unnd a solicitud condicional es Utilizado Para volvera girar el recurso sólo si ese recurso has cambiado. Para obtener más información sobre el código de error 412 Precondition Failed, consulte RFC7232, Sección 4.2

413: Solicitar entidad demasiado grande

el 413 Solicitar entidad demasiado grande Error código de estado Indica que el servidor wenfermo no aceptar y procesar la solicitud due a la solicitud Cuerpo ser más grande que el servidor permitir o puede Proceso. Tales ejemplos incluyen la carga de un archivo en el que el expediente supera la Máximo tamaño de la carga establecido por el servidor o cuando se haya superado el número máximo de cargas. En los casos en quee 413 Solicitar error de entidad demasiado grande se produce, el servidor puede cerrar la conexión por completo para evitar que el cliente continuar enviando la solicitud. En algunos casos,, eso Yos probablemente el Servidor permitiría al cliente reintentar la solicitud, siYos una condición temporal, Y debe incluir ese mensaje de nuevo al cliente. However, Yos posible la solicitud podría hacer que el propio servidor se quede sin espacio en disco. En este caso, el error de almacenamiento insuficiente 507 es la respuesta que el cliente debe recibir de vuelta. See RFC7231, Sección 6.5.11 para obtener más información.

414: URI demasiado largo

No es una respuesta de servidor muy común, el código de estado de error 414 URI demasiado largo significa que el servidor rechazó la solicitud de cliente debido a la La dirección URL es más larga de lo que el servidor puede procesar. Hermanowsers y motores de búsqueda ponen límites a la longitud de las direcciones URL, en parte para evitar ataques DDoS o errores de código,pero la ruta de una URL o HTTP no tienen límites explícitos. Por lo tanto, si limit supera lo establecido por el servidor, se producirá el error 414 URI demasiado largo. Para obtener más información sobre el código de error 414 URI demasiado largo, consulte RFC7231, Sección 6.5.12

415: Tipo de soporte no compatible

El código de estado de error 415 Unsupported Media Type indica que el servidor no puede procesar el cuerpode la solicitud o parte del cuerpodela solicitud, debido a un formato de medios no admitido. Incluso si se admite la solicitud del cliente, el error 415 puede ser si hay contenido no admitido en el cuerpo de la solicitud. Un código de error 415 Unsupported Media Type es como el código de estado 406 Not Acceptable. La diferencia es que un código de error 406 No aceptable no se debe al contenido del encabezado o codificación, debido al valor establecido dentro del encabezado HTTP. Asegurarse de que el servidor puede procesar el formato definido junto con el envío de la solicitud con el formulario correcto evitará que se produceun código de estado de error de tipo de medios no compatible 415 . See RFC7231, Sección 6.5.13 para obtener más información.

416: Rango no satisfiable

Como se mencionó con el código de estado de solicitud parcial 206, es posible que los clientes/navegadores soliciten una respuesta parcial de la r del servicio,ya sea que is una parte específica de un archivo o vídeo, por ejemplo. Los clientes y servidores utilizan lo que se denomina ejecutar estas solicitudes. Sin embargo, si el servidor no soportan este tipode solicitudes, simplemente devolverá todo el resou junto con una respuesta de 200 OK. Si el servidor admite solicitudes de rango,t es donde el 416 Solicitud parcial Error código de estado entra en la imagen y devolverá lo que el cliente está pidiendo. En una situación en la que el servidor admite solicitudes de rango, pero la servidor does no de acuerdo con el Petición recibido porque lo hace No dentro del rango O posiblemente más allá el rango especificado, el rango 416 No Satisfiable Error código de estado será devuelto. See RFC7233, Sección 4.4 para más información.

417: La expectativa fracasó

Los clientes pueden usar un encabezado Expect para indicar que espera un comportamiento específico del servidor. Como se describe en el código de estado 100 Continue, los clientes pueden consultar con el servidor si aceptará una solicitud. Si lo hace, el servidor responderá con el código de estado 100 Continue. Si no es así, tél 417 La expectativa fracasó Error código de estado Indica ese el servidor lo hizo No entender el Esperar Rúbrica o apoyarlo, por lo tanto, puedeNo procesar el clienT Petición. Para obtener más información sobre el código de error 417 Expectation Failed, consulte RFC7231, Sección 6.5.14

418-420: Sin asignar

Error status códigos 418-421 están actualmente sin asignar, sin embargo, código de estado 418 Estoy un Little Teapot se utiliza en algunos casos. Creado como una broma de April Fool, ha ganado algo de tracción y es a veces se utiliza como una broma o huevo de Pascua y no se utiliza para fines cotidianos reales. La mayoría de los navegadores lo ignoran, ya que no es un código deestado oficial. Otro en esta categoría es el 420 Enhance Your Calm código de estado de error que fue introducido por Twitter. eso is an códigode error que indica a los clientes que ar e siendo tarifa limitada, which es una restricción en el número de solicitudes que pueden hacer dentro de un período de tiempo especificado. Desde 1989,el Editor RFC publicará las RFC más humorísticas. Wikipedia tiene un resumen completo de las RFC más humorísticas de April Fool.

421: Solicitud mal dirigida

Introducido con el protocolo HTTP/2, el 421 Solicitud mal dirigida Error código de estado significa que el servidor received una solicitud que fue No destinado a ese servidor específico y no puede responder adecuadamente. Esto puede suceder si el DNS (sistema de nombres de dominio) se fija a la dirección IP incorrecta. Clientes están obligados a incluir una Host encabezado en la solicitud. Esto también puede ocurrir con sitios que tienen un solo Ssl certificado de varios dominios. Esto puede ser causado por unN problema con el proveedor de alojamiento y / o navegador específico utilizado, por lo que puede requerir una gran cantidad de trabajo para entender realmente dónde se encuentra el problema. Si un servidor sabe que un dominio no está configurado en el request, responderá con la solicitud 421 Mal dirigida respuesta de error. See RFC7540, Sección 9.1.2 para más información.

422: Entidad inprocesable

Un 422 Inprocesable Entidad Error código de estado Indica un problema con la contenido de la sintaxis de una solicitud. el disposición de la solicitud fue entendido por el servidorPero el campos dentro de la solicitud no son válidos o lo hace No coincide con lo que el servidor espera. Como 102 Procesamiento y 207 Multi-Códigos de estado, un 422 Inprocesable Entidad Error código es parte del protocolo WebDAV y a menudo se utiliza con servicios web/API. Por lo general, un 400 Bad Request es la respuesta de recomendación, pero si se admite WebDAV, entonces t422 Inprocesable Entidad debe utilizarse. See RFC4918, Sección 11.2 para más información.

423: Cerrado

Al igual que el código de estado de error de entidad no procesable 422, el error 423 Locked código de estado también forma parte del protocolo WebDAV. El código de estado 423 Locked indica que une, recursos o directamente, por ejemplo, no se pueden editar. Su propósito es evitar que varios usuarios actualicen un archivo, recurso, etc., simultáneamente. Estos recursos se pueden desbloquear para su edición, wgallina necesaria. Para obtener más información sobre el código de error 423 Locked, consulte RFC4918, Sección 11.3

424: Dependencia fallida

Otro código de estado admitido por WebDav protocolo; la dependencia fallida 424 código de estado de error indica error en la solicitud del cliente debido a una dependencia de otra solicitud que también ha fallado. WebDAV utiliza un método conocido como PROPPATCH para actualizar ciertas propiedades resource. Para indicar si un recurso se actualizó correctamente o no, WebDAV utiliza respuestas de código de estado HTTP estándar. Además, el código de estado de dependencia con error 424 solo se utiliza en caso de que la respuesta en el cuerpo HTTP tenga el 207 Multi-Strespuesta atus. So, si se utiliza PROPPATCH y el recurso no se actualiza, enviará un código de estado 4xx que indica hay un error al actualizar el recurso, el código de error de dependencia con error 424 también se enviará junto con las otras solicitudes que dependían de que esa actualización se realizara correctamente pero no se pudo realizar . See RFC4918, Sección 11.4 para obtener más información.

425: Demasiado temprano

No es un código de estado HTTP común que se utiliza hoy en día, el código de respuesta de error demasiado temprano 425 se utiliza en situaciones donde un cliente HTTP se conecta a un cliente HTTPS. Durante el proceso, puede tomar mucho tiempo establecer una conexión entre el servidor y el cliente. Este proceso puede plantear un problema de seguridad, por lo que el servidor le dirá al cliente que vuelva a intentar la solicitud hasta que la conexión TLS (Transport Layer Security) segura se haya Hecho. En ese caso, se devolverá el código de estado 425 Too Early. Para obtener más información sobre el código de error demasiado temprano 425, consulte RFC8470, Sección 5.2

426: Se requiere actualización

El código de estado de error requerido de la actualización 426 indica al cliente que necesita utilizar un protocolo más nuevo con el fin de enviar solicitudes al servidor. Por ejemplo, el cliente puede estar utilizando y la versión anterior de HTTP, como HTTP/1.0, pero el servidor Requiere HTTP2.0. El servidor no aceptará la solicitud, pero responderá al clienT Indicando protocolo o protocolos aceptables. Una vez que el cliente ha actualizado a la protocolo(s) requerido(s), el servidor aceptará solicitudes del cliente. Para obtener más información sobre el código de error 426 Upgrade Required, consulte RFC7231, Sección 6.5.15

427: Sin asignar

Error status código 427 está actualmente sin asignar.

428: Precondición requerida

El código de estado de error 428 Precondition Required indica al cliente que la solicitud al servidor debe ser una solicitud condicional. Como se menciona en el 304 Código de estado no modificado, un cliente puede enviar una solicitud condicional al servidorComo If-Match, If-None-Match, If-Modified-Since, If-Unmodified-SinceO If-Range. Sin embargo, estas solicitudes condicionales no son Obligatorio. Si el servidor los requiere, el servidor Indica esto respondiendo con el código de error 428 Precondition Required. Esto es un poco similar a el 412 Precondition Failed código de error, pero el 412 Error en la condición previa código de error se devuelve sólo si el cliente incluyó una solicitud condicional en el encabezado que hace No Match el estado del recurso en el servidor‘s Lado. Al notificar a los usuarios que las solicitudes deben ser condicionales por naturaleza, esto garantiza que los usuarios están trabajando con los archivos o recursos adecuados y ayuda a prevenir usuarios de cambios potencialmente sobrescritos. See RFC6585, Sección 3 para más información.

429: Demasiadas solicitudes

Al igual que el nombre del error código indica, el código de estado de error429 Too Many Requests significa que se implementa lalimitación de velocidad, y que el client superó el límite de cómo muchas solicitudes puede hacer en una cantidad de tiempo especificada. Junto con la respuesta de error 429 Too Many Requests, debe ser Indicado cuánto tiempo esperar antes de Iniciar una nueva solicitud al servidor, pero no es Antes Obligatorio para hacerlo. Para obtener más información sobre el código de error Demasiadas solicitudes, consulte RFC6585, Sección 4

430: Sin asignar

El código de estado de error 430 está actualmente sin asignar, sin embargo, en un momento se propuso ser el código de error 430 Bloquearía dentro delprotocolo HTTP/1.1. La intención era servir de respuesta a lo que es conocido como Pipelining. Esto permitió a los clientes enviar varias solicitudes, a través de una conexión TCP, mientras esperaba a que el servidor respond. Yot nunca oficialmente llegó a la estándar como el protocol HTTP seactualizó a HTTP/2.0 y el soporte para la canalización nunca fue ampliamente adoptado.

431 Encabezados de solicitud demasiado grandes

El código de estado de error 431 Request Headers Too Large indica que el cliente envió una request de encabezado que supera el límitepermitido. Diferentes servidores web tienen diferentes límites de tamaño permitidos cuando se trata de encabezados. Esto podría deberse a que una solicitud de encabezado individual es demasiado grande o debido a la totalidad de la combinación tamaño de todos los las solicitudes de encabezado. En la mayoría de los casos, esto puede ser fácil de remediar, ya que por lo general es causado por el envíode demasiadas cookies o cookies que son demasiado grandes en tamaño de archivo. Para obtener más información sobre el código de error 431 Request Headers Too Large, consulte RFC6585, Sección 5

432-450: Sin asignar

Los códigos de estado de error 432 a 450 no están asignados actualmente.

451: No disponible por razones legales

Error scódigo tatus 451 No disponible por razones legales Indica el servidor se niega a servir el contenido solicitado debido a Legal Razones y también debe incluir el motivo del error en la respuesta al usuario. Las razones para usar el código de estado de error 451 Unavailable Due to Legal Reasons podrían incluir gobiernos que censuran contenido específico, contenido que viola las leyes de derechos de autor, como la DMCA (Digital Millennium Copyright Acts), o contenido que infrinja leyes u órdenes judiciales. El 403 Prohibido y 404 No encontrado error códigos de estado se utilizan a veces en lugar del código de estado de error 451, pero el código de estado de error 451 proporciona más información o explicación en why el error está ocurriendo. Los usuarios suelene 451 error mediante la implementación de VPN para acceder al contenido. See RFC7725, Sección 3 para obtener más información.

452-499: Sin asignar

Los códigos de error 452-499 no están asignados actualmente.

 

5xx: Error del servidor

Al igual que los códigos de estado 4xx, los códigos de estado 5xx indican que hay un error,sin embargo, el error en cuestión no es probable debido a una mala conexión o el propio navegador. Los códigos de estado 5xx indican hay un problema a nivel de servidor y no puede procesar el solicitud del cliente. Junto con el error, el servidor debe responder con una explicación del error, si es una condición temporal o permanente, y cómo se puede remediar.

 

500: Error interno del servidor

El código de estado 500 Internal Server Error simplemente significa que el servidor encontró un problema y no puede procesar la solicitud. Típicamente, el código de error interno del servidor 500 utilizado más como un código de error genérico del servidor si el problema exacto noentra en ninguno de los otros 5xx Códigode estado de error del servidor 5xx Especificaciones. Tél 500 Código de error interno del servidor es probablemente el más utilizados de los códigosde clasificación 5xx Server Error . Consulte RFC7231, Sección 6.6 para obtener más información.

501: No implementado

Un 501 no implementado códigos de estado de error se produce cuando el servidor No reconocer el método de la solicitud y, por lo tanto, no puede support o procesar la solicitud. eso Yos Como el código de estado de error del cliente 405 Method Not AllowedPero un código de estado de error 501 No implementado podría Indicar que el método de solicitud del cliente es válido, simplemente no es compatible con el servidor. El estado de error Método 405 no permitido Indicar que el método llamado por el cliente es No Apoyado y debe No He estado Utilizado. Ver RFC7231, Sección 6.6.2 para más información.

502: Puerta de enlace incorrecta

El código de estado de error 502 Bad Gateway significa que un servidor está actuando como proxy y recibió una respuesta de un servidor de origen que no es válido. eso Yos posible que Yos debido a un servidor sobrecargado y el cliente puede volver a enviar la solicitud, pero en la mayoría de los casos, eso Yos pendiente Para un problema con el servidor web O CDN (Red de distribución de contenido) sentado entre el cliente y el servidor y puede Requieren Adicional solución de problemas con el proveedor de alojamiento para entender por qué se está lanzando el error. Ver RFC7231, Sección 6.6.3 para obtener más información.

503: Servicio no disponible

El código de estado de error 503 Service Unavailable indica que el servidor está actualmente sobrecargado con solicitudes o fuera de recursos,actualmente es inmantenimiento, o posiblemente en la aplicación a la que están intentando acceder está inactivo, y el servidor no puede completar la solicitud debido al estado actual. Los clientes a veces verán un mensaje junto con el código de estado de error 503 Service Unavailable que les indica que vuelvan a intentar la solicitud Más tarde. Sin embargo, no puede proporcionar una explicación definitiva de cuándo o cuánto tiempo puede durar el código de estado de error no disponible del servicio 503. Consulte RFC7231, Sección 6.6.4 para obtener información.

504: Tiempo de espera de la puerta de enlace

Al igual que el código de estado de error 502 Bad Gateway, el código de estado de error de tiempo de espera de puerta de enlace 504 se utiliza cuando el servidor actúa como proxy, pero responderá con un 504 Gateway Timeout código de estado de error si la respuesta de unN servidor de origen tarda demasiado tiempo en responder. Se debe utilizar un código de estado de error de 502 Bad Gateway en los casos en que la respuesta no sea válida o no recibido por el servidor proxy En absoluto. El mensaje junto con el 504 Gatemanera tiempo de espera puede indicar y recomendar que el cliente intente reenviar la solicitud. Ver RFC7231, Sección 6.6.5 para más información.

505: Versión HTTP no compatible

Un código de estado de error 505 HTTP Version Not Supported significa que el servidor no admite la versión del protocolo HTTP utilizado en el mensaje de la solicitudy, por lo tanto,no puede procesar la solicitud. Junto con la versión HTTP 505 No se admite el códigode estado de error , la respuesta del servidor debe incluir unmensaje que indique por qué no se admite ese protocolo HTTP específico y qué protocolos se admiten. Consulte RFC7231, Sección 6.6.6 para obtener más información.

506: Variant también negocia

La variante 506 también negocia es un código de estado HTTP experimental y no es parte del estándar hoy en día. Una variante 506 también negocia indica que hay un problema de configuración interna con el servidor debido a problemas de negociación de contenido. La negociación de contenido permite a los clientes enviar múltiples encabezados de aceptación y le dice al servidor qué representación específica de un recurso para servir como se indica por el navegador. Esto podría ser para servir el idioma correcto, documento formaunat, etc.. A pesar de que la variante 506 también negocia el código de estado de error está en Un experimental y no oficialmente parte del estándar HTTP, se utiliza en casos raros. Algunos usuariosde Google Playencontraron este problema en el pasado al intentar descargar varias versiones de una aplicación, lo que provocóque losdispositivos ir intentaran continuamente descargar la aplicación en un procesode bucle cerrado. Consulte RFC2295, Sección 8.1 para obtener más información.

507: Almacenamiento insuficiente

Un código de estado de error del servidor de almacenamiento insuficiente 507 también forma parte del protocolo WebDAV. El código de estado de error de almacenamiento insuficiente 507 indica al client thatla solicitud,como un PUT o POST solicitud, era demasiado grande en tamaño de archivo. También puede indicar que el servidor tiene temporalmente se queda sin almacenamiento. Consulte RFC4981, Sección 11.5 para obtener más información.

508: Bucle detectado

El 508 Loop Detectado Servidor código de estado de error, al igual que el código de error del servidor de almacenamiento insuficiente 507, forma parte del protocolo WebDAV. Dentro del protocolo WebDAV, eso Yos posible que el cliente pueda hacer una solicitud a un servidor para todo un directorio y crear un objetivoDónde ese mismo directorio, lo que resulta en un bucle de solicitud/respuesta infinito. El código de estado de error del servidor 508 Loop Detected Indica que el servidor Terminó la solicitud del clienteEspecíficamente Profundidad: EnFinity, porque el servEr Identificado la solicitud como resultando en una ibucle de nfinite, volviendo a llamarse repetidamente a sí mismo. Ver RFC5842, sección 7.2 para más Información.

509: Sin asignar

El código de estado de error del servidor 509 no está asignado actualmente.

510: No extendido

Un código de estado de error del servidor 510 Not Extended está actualmente en estado propuesto/experimental y no forma parte de la especificación de código de estado HTTP estándar. El 510 Not Extended indica al cliente que la solicitud requiere una solicitud HTTP extendida. Si el servidor responde con el código de estado de error del servidor 510 Not Extended, también debe incluir cómo el client debe remEdy su solicitud, pero la especificación hace No Explícitamente Estado ese. allí‘s debate si tsu scayera bajo la clasificación de errores del servidor 5xx ya que podría ser visto como un error de cliente 4xx, pero ya que Lo es formalmente no forma parte de la norma, Yos no relevHormiga y rara vez se utiliza para el uso diario. Ver RFC2774, Sección 7 para más información.

511: Se requiere autorización de red

El código de estado de error del servidor requerido de la autorización de red 511 que requiere que el cliente se autentique para obtener acceso a una red. Por ejemplo, es posible que los usuarios vean esto al intentar conectarse a una red Wi-Fi pública en una empresa y los usuarios deben aceptar sus términos y condiciones antes de que se les conceda acceso. Junto con la autorización de red 511 requerida respuesta de error del servidor, los usuarios también deben ser dirigidos a donde pueden iniciar sesión. Consulte RFC6585, Sección 6 para obtener más información.

512-599: Sin asignar

Los códigos de estado de error de servidor 512-599 están actualmente sin asignar, pero algunas empresas pueden usar cualquiera de estos como mensajes de error de servidor personalizados a los clientes.

 

Supervisión de las respuestas del código de estado HTTP

Para ver una lista de códigos de estado para una URL específica de primera mano, puede comprobar la pestaña Herramientas de desarrollador dentro de su exploraciónR. Junto con las métricas de velocidad de carga de la página, también puede ver cualquier respuesta del servidor, junto con todos los códigos de estado HTTP asociados, para asegurarse de que todo en su página se está cargando y Representación Correctamente.

Para un enfoque de supervisión más proactivo y automatizado, las soluciones de monitoreo profesional de Dotcom-Monitor pueden asegurarse de que cada vez que un usuario encuentra un código de error HTTPespecífico, se le notifica a losequipos r inmediatamente so que pueden remediar rápidamente el problema. También puede utilizar el Función de filtros para eliminar códigos de estado HTTP individuales de tareas, alertas e informes,por lo que no tiene en cuenta los códigos de estado HTTP que no sean relevantes para sus necesidades específicas.