SignificadosHTTP Status Code
Familia del 100 (Respuestas informativas)
El código de respuesta informativa HTTP 100 Continue tiene el propósito de informar al cliente que el servidor ha recibido y está procesando los encabezados de la solicitud inicial, y que el cliente puede proceder a enviar el cuerpo de la solicitud.
Explicación:
Solicitud del cliente: El cliente envía una solicitud al servidor con el encabezado
Expect: 100-continue. Esto indica que el cliente desea una confirmación de que los encabezados de la solicitud han sido recibidos y aceptados antes de enviar el cuerpo de la solicitud (especialmente útil para solicitudes grandes o críticas).Respuesta del servidor: Si los encabezados son aceptables, el servidor responde con un código de estado 100 Continue, indicando al cliente que puede proceder a enviar el cuerpo de la solicitud. Si los encabezados no son aceptables, el servidor puede responder con un código de error (como 4xx o 5xx) en lugar de 100 Continue.
Este mecanismo es útil para optimizar el uso de la red y los recursos del servidor, especialmente en casos donde el cuerpo de la solicitud puede ser grande. Evita que el cliente envíe grandes cantidades de datos solo para que el servidor los rechace por problemas en los encabezados.
El código HTTP 100 Continue es una señal del servidor al cliente de que puede continuar con su solicitud después de que los encabezados han sido procesados y aceptados.
El código de respuesta HTTP 101 Switching Protocols indica que el servidor acepta cambiar el protocolo de comunicación utilizado a uno diferente, como ha sido solicitado por el cliente. Este código es parte de la respuesta del servidor y confirma que la solicitud del cliente para cambiar el protocolo ha sido aceptada.
Explicación:
Solicitud del cliente: El cliente envía una solicitud al servidor con un encabezado
Upgradeque especifica el nuevo protocolo al que quiere cambiar. Este encabezado indica el deseo del cliente de cambiar de protocolo, como por ejemplo de HTTP/1.1 a HTTP/2 o a WebSocket.Respuesta del servidor: Si el servidor está de acuerdo en cambiar el protocolo, responde con un código de estado 101 Switching Protocols. En la respuesta, el servidor incluye un encabezado
Upgradeque indica el nuevo protocolo al que se está cambiando.
Por ejemplo, un navegador web puede solicitar cambiar a un protocolo WebSocket para establecer una conexión más adecuada para comunicaciones en tiempo real. Si el servidor soporta WebSocket y está dispuesto a cambiar, responderá con un código 101 y procederá a cambiar al nuevo protocolo.
El código 101 Switching Protocols es una señal del servidor de que el cambio de protocolo solicitado por el cliente ha sido aceptado y se está efectuando.
El código de respuesta HTTP 102 Processing es una respuesta informativa utilizada principalmente en entornos de WebDAV (Protocolo de Control de Versiones Distribuido basado en la Web) para indicar que el servidor ha recibido y está procesando la solicitud, pero no hay respuesta final disponible todavía.
Explicación:
Propósito: El código 102 Processing informa al cliente que la solicitud ha sido aceptada y que el servidor está trabajando en ella. Esto es útil para evitar que el cliente asuma que la solicitud ha fallado debido a una falta de respuesta inmediata.
Uso común: Este código es particularmente útil para operaciones que pueden llevar un tiempo considerable en completarse, como el procesamiento de archivos grandes o complejas operaciones de WebDAV, que pueden involucrar múltiples suboperaciones que deben ser completadas antes de que la respuesta final esté disponible.
Respuesta del servidor: Mientras el servidor está ocupado procesando la solicitud, responde con un 102 Processing para mantener al cliente informado del progreso. Una vez que el servidor ha terminado de procesar la solicitud, enviará la respuesta final con el código de estado apropiado (por ejemplo, 200 OK, 201 Created, 4xx Client Error, 5xx Server Error, etc.).
El código HTTP 102 Processing es utilizado para informar al cliente que el servidor está trabajando en la solicitud y que aún no hay una respuesta final disponible. Este código ayuda a gestionar las expectativas del cliente durante operaciones prolongadas.
El código de respuesta HTTP 103 Early Hints es una respuesta informativa que permite a un servidor enviar algunos encabezados de respuesta anticipadamente, antes de que se haya preparado la respuesta final. Esto es útil para mejorar el rendimiento de carga de una página web al permitir que el navegador del cliente comience a cargar recursos importantes (como CSS, JavaScript, o imágenes) mientras se sigue generando la respuesta completa.
Aquí hay una explicación más detallada:
Propósito: El código 103 Early Hints se utiliza para proporcionar al cliente algunos de los encabezados de la respuesta final antes de tiempo. Esto ayuda a que el navegador pueda comenzar a cargar los recursos necesarios, como archivos CSS, JavaScript, y otros, mientras espera la respuesta completa del servidor.
Uso común: Este código es especialmente útil para mejorar la velocidad de carga de las páginas web. Al recibir los encabezados anticipadamente, el navegador puede iniciar conexiones y solicitudes adicionales para los recursos especificados en estos encabezados, lo que reduce el tiempo total de carga de la página.
Respuesta del servidor: El servidor envía una respuesta 103 Early Hints con los encabezados que desea adelantar, como
Linkheaders que indican recursos críticos que el navegador debería precargar. Luego, el servidor sigue procesando la solicitud y eventualmente envía la respuesta final con el código de estado definitivo (como 200 OK).
Ejemplo de uso:
El servidor podría enviar una respuesta 103 Early Hints con un encabezado Link que señala hojas de estilo CSS y scripts JavaScript esenciales:
HTTP/1.1 103 Early Hints
Link: </style.css>; rel=preload; as=style
Link: </script.js>; rel=preload; as=script
Luego, el servidor envía la respuesta final:
HTTP/1.1 200 OK Content-Type: text/html
El código HTTP 103 Early Hints permite al servidor enviar algunos encabezados de respuesta anticipadamente para que el navegador del cliente pueda empezar a cargar recursos importantes antes de recibir la respuesta completa. Esto ayuda a mejorar la eficiencia y velocidad de carga de las páginas web.
Familia del 200 (Respuestas Satisfactorias)
El código de respuesta HTTP 200 OK significa que la solicitud realizada por el cliente ha sido exitosa y que el servidor ha devuelto la información solicitada. Es uno de los códigos de estado más comunes y generalmente indica que todo ha funcionado correctamente. Aquí hay una explicación más detallada:
Propósito: Indica que la solicitud ha sido recibida, comprendida y aceptada con éxito por el servidor.
Uso común:
- Páginas web: Cuando un navegador solicita una página web y el servidor la encuentra y la entrega correctamente, se utiliza el código 200 OK.
- APIs: En las APIs, el código 200 OK indica que la operación solicitada, como obtener datos o completar una acción, se ha realizado correctamente.
Contenido de la respuesta: La respuesta con un código 200 OK generalmente incluye el contenido solicitado en el cuerpo de la respuesta. Este contenido puede ser una página HTML, datos en formato JSON o XML, un archivo, etc.
Ejemplo de uso:
Solicitud de página web:
GET /index.html HTTP/1.1
Host: www.ejemplo.com
Respuesta del servidor:
HTTP/1.1 200 OK
Content-Type: text/html<!DOCTYPE html>
<html>
<head>
<title>Página de Ejemplo</title>
</head>
<body>
<h1>¡Hola, mundo!</h1>
</body>
</html>
El código HTTP 200 OK es una señal de que la solicitud del cliente ha sido procesada con éxito por el servidor y que la respuesta incluye el contenido solicitado.
El código de respuesta HTTP 201 Created indica que la solicitud del cliente se ha completado con éxito y ha resultado en la creación de un nuevo recurso. Aquí hay una explicación más detallada:
Propósito: Informa al cliente de que la solicitud ha sido procesada correctamente y que un nuevo recurso ha sido creado en el servidor como resultado de la solicitud.
Uso común:
- APIs RESTful: Es común en operaciones de creación de recursos, como cuando se envía una solicitud POST para crear un nuevo usuario, una nueva entrada de blog, un nuevo ítem en una base de datos, etc.
- Subida de archivos: Cuando un archivo se carga y se guarda correctamente en el servidor.
Contenido de la respuesta:
- Localización del nuevo recurso: La respuesta generalmente incluye un encabezado
Locationque contiene la URL del nuevo recurso creado. - Representación del recurso: A veces, la respuesta también incluye una representación del recurso recién creado en el cuerpo de la respuesta.
- Localización del nuevo recurso: La respuesta generalmente incluye un encabezado
Ejemplo de uso:
Solicitud para crear un nuevo usuario:
POST /usuarios HTTP/1.1
Host: www.ejemplo.com
Content-Type: application/json{
“nombre”: “Juan Pérez”,
“correo”: “[email protected]”
}
Respuesta del servidor:
HTTP/1.1 201 Created
Location: /usuarios/123
Content-Type: application/json{
“id”: 123,
“nombre”: “Juan Pérez”,
“correo”: “[email protected]”
}
El código HTTP 201 Created indica que la solicitud ha sido exitosa y que un nuevo recurso ha sido creado. La respuesta incluye la ubicación del nuevo recurso y, opcionalmente, una representación del mismo.
El código de respuesta HTTP 202 Accepted indica que la solicitud ha sido recibida y aceptada para su procesamiento, pero que el procesamiento no se ha completado aún. Este código no garantiza que la solicitud se completará con éxito, solo que ha sido aceptada y está en proceso.
Explicación:
Propósito: Informa al cliente de que la solicitud ha sido aceptada y que el servidor está trabajando en ella, pero que el procesamiento se llevará a cabo en un momento posterior. Es útil para operaciones que pueden llevar un tiempo considerable en completarse.
Uso común:
- Procesamiento en segundo plano: Cuando una operación necesita ser procesada de forma asíncrona. Por ejemplo, la solicitud de procesamiento de un archivo grande, el inicio de un trabajo de importación de datos, o la ejecución de una tarea en segundo plano.
- APIs: En las APIs, especialmente en aquellos sistemas que realizan operaciones prolongadas, como la generación de informes, el envío de correos masivos o la ejecución de scripts complejos.
Contenido de la respuesta:
- Información adicional: Aunque no es obligatorio, la respuesta puede incluir información sobre el estado actual del procesamiento o un enlace a un recurso donde se pueda consultar el progreso o el resultado de la operación.
- Encabezados: Puede incluir encabezados como
Locationpara proporcionar una URL donde el cliente puede obtener el estado de la operación pendiente.
Ejemplo de uso:
Solicitud para iniciar una tarea prolongada:
POST /procesar-datos HTTP/1.1
Host: www.ejemplo.com
Content-Type: application/json{
“dataset”: “datos_grandes.csv”
}
Respuesta del servidor:
HTTP/1.1 202 Accepted
Location: /estado-proceso/123
Content-Type: application/json{
“mensaje”: “La solicitud ha sido aceptada y está siendo procesada.”,
“id_proceso”: 123,
“estado”: “pendiente”
}
El código HTTP 202 Accepted indica que la solicitud ha sido aceptada para su procesamiento, pero que el procesamiento no se ha completado aún. Es una forma de señalar al cliente que la operación se está manejando de manera asíncrona y que puede verificar el estado más adelante.
El código de respuesta HTTP 203 Non-Authoritative Information indica que la solicitud se ha procesado correctamente, pero la información devuelta puede provenir de una copia local o de una fuente tercera, en lugar de la fuente original del servidor. Esto significa que el contenido puede haber sido modificado por una entidad intermedia (como un servidor proxy) antes de ser entregado al cliente.
Explicación:
Propósito: Informar al cliente que la respuesta contiene información válida, pero no autorizada por la fuente original. La información puede haber sido modificada por un servidor proxy o algún otro intermediario.
Uso común:
- Servidores proxy: Cuando un proxy intermedio responde a una solicitud con contenido que ha modificado o validado.
- Cachés: En situaciones donde el contenido es servido desde un caché intermedio que puede haber alterado la información.
Contenido de la respuesta:
- Aunque la respuesta tiene un código de estado 200 OK, el contenido puede no ser una representación exacta del recurso del servidor original.
- La respuesta incluye los datos solicitados, pero el cliente debe tener en cuenta que esta información no proviene directamente del servidor de origen.
Ejemplo de uso:
Solicitud al servidor:
GET /datos HTTP/1.1
Host: www.ejemplo.com
Respuesta del servidor proxy:
HTTP/1.1 203 Non-Authoritative Information
Content-Type: application/json{
“datos”: “Estos datos pueden haber sido modificados por el proxy.”
}
El código HTTP 203 Non-Authoritative Information indica que la solicitud se ha completado con éxito, pero la información devuelta puede haber sido modificada por un intermediario y no proviene directamente de la fuente original del servidor.
El código de respuesta HTTP 204 No Content indica que la solicitud se ha procesado correctamente y el servidor no necesita devolver ningún contenido en el cuerpo de la respuesta. Este código es útil en situaciones donde no es necesario enviar datos al cliente después de una operación exitosa.
Explicación:
Propósito: Informar al cliente de que la solicitud se ha procesado con éxito, pero que no hay contenido para enviar en la respuesta. Es adecuado para operaciones donde no se necesita una respuesta en el cuerpo, como cuando se actualizan recursos con una solicitud PUT o se realizan acciones con una solicitud DELETE.
Uso común:
- Operaciones de actualización: Después de una solicitud PUT para actualizar un recurso.
- Eliminación de recursos: Después de una solicitud DELETE para eliminar un recurso.
- Operaciones sin respuesta requerida: Cuando una acción se completa y no es necesario devolver datos adicionales al cliente.
Contenido de la respuesta:
- No hay contenido en el cuerpo de la respuesta.
- Puede incluir encabezados relevantes, como
Content-LocationoETag.
Ejemplo de uso:
Solicitud para actualizar un recurso:
PUT /usuarios/123 HTTP/1.1
Host: www.ejemplo.com
Content-Type: application/json{
“nombre”: “Juan Pérez Actualizado”
}
Respuesta del servidor:
HTTP/1.1 204 No Content
El código HTTP 204 No Content indica que la solicitud se ha procesado con éxito, pero no hay contenido que devolver en la respuesta. Este código es útil para operaciones donde la acción solicitada se ha completado y no es necesario enviar datos adicionales al cliente.
El código de respuesta HTTP 205 Reset Content indica que la solicitud se ha procesado con éxito y el servidor desea que el agente del usuario (por ejemplo, el navegador web) restablezca la vista que ha causado la solicitud. Esto puede implicar, por ejemplo, limpiar un formulario de entrada o restablecer la interfaz de usuario a su estado original.
Explicación:
Propósito: Informar al cliente de que la solicitud se ha completado con éxito y que debe reiniciar la vista o la interfaz de usuario. Es especialmente útil después de acciones como el envío de formularios.
Uso común:
- Formularios web: Después de enviar un formulario, el servidor puede responder con un código 205 para indicar que el formulario debe ser limpiado o restablecido.
- Interfaz de usuario: Para indicar que cualquier entrada o estado temporal del cliente debe ser restablecido a su estado predeterminado.
Contenido de la respuesta:
- No hay contenido en el cuerpo de la respuesta.
- Puede incluir encabezados relevantes, pero el cuerpo de la respuesta debe estar vacío.
Ejemplo de uso:
Solicitud para enviar datos de un formulario:
POST /submit-form HTTP/1.1
Host: www.ejemplo.com
Content-Type: application/x-www-form-urlencodednombre=Juan&apellido=Pérez
Respuesta del servidor:
HTTP/1.1 205 Reset Content
El código HTTP 205 Reset Content indica que la solicitud se ha procesado con éxito y que el cliente debe reiniciar o limpiar la vista o la interfaz de usuario que provocó la solicitud. Este código es útil para garantizar que la interfaz del usuario vuelva a un estado predeterminado después de una operación exitosa.
El código de respuesta HTTP 206 Partial Content indica que el servidor ha cumplido con una solicitud GET para un recurso, pero solo una parte del recurso ha sido devuelta. Esto es comúnmente utilizado cuando el cliente solicita una parte específica de un archivo, utilizando encabezados de rango, para facilitar la descarga por partes o la transmisión de medios.
Aquí hay una explicación más detallada:
Propósito: Informar al cliente de que la solicitud de un rango específico de contenido ha sido exitosa y que solo se ha enviado esa parte del contenido.
Uso común:
- Descargas interrumpidas y reanudables: Permite a los clientes reanudar descargas interrumpidas solicitando solo las partes del archivo que aún no se han descargado.
- Transmisión de videos y audios: Los clientes pueden solicitar partes específicas de archivos de video o audio para la reproducción en tiempo real.
Encabezados relacionados:
- Range: El cliente envía este encabezado para especificar el rango de bytes que desea recibir.
- Content-Range: El servidor utiliza este encabezado en la respuesta para indicar qué parte del contenido se está devolviendo.
Ejemplo de uso:
Solicitud del cliente para una parte específica de un archivo:
GET /video.mp4 HTTP/1.1
Host: www.ejemplo.com
Range: bytes=0-1023
Respuesta del servidor con parte del archivo:
HTTP/1.1 206 Partial Content
Content-Type: video/mp4
Content-Range: bytes 0-1023/10000[Aquí irían los primeros 1024 bytes del archivo de video]
El código HTTP 206 Partial Content indica que el servidor ha cumplido con la solicitud de entregar una parte específica del contenido. Es especialmente útil para manejar descargas grandes, interrumpidas o transmisiones de medios, permitiendo que los clientes soliciten y reciban partes específicas del recurso en lugar de descargarlo completo en una sola solicitud.
El código de respuesta HTTP 207 Multi-Status es específico del protocolo WebDAV (Extensiones para Autoría y Versionado Distribuido Basado en la Web). Este código indica que la respuesta contiene información sobre múltiples recursos, y cada uno puede tener un código de estado diferente asociado.
Explicación:
Propósito: Informar al cliente que la solicitud ha afectado a múltiples recursos y proporcionar un código de estado separado para cada uno de ellos. Es útil cuando una sola solicitud WebDAV afecta a varios archivos o directorios.
Uso común:
- Operaciones WebDAV: Utilizado en respuestas a solicitudes WebDAV como PROPFIND, PROPPATCH, y MOVE, que pueden involucrar múltiples recursos.
- Resultados detallados: Permite devolver resultados detallados de operaciones complejas que involucran varios recursos, indicando el éxito o fallo de cada uno individualmente.
Formato de la respuesta:
- La respuesta es un documento XML que contiene múltiples códigos de estado, cada uno correspondiente a un recurso diferente.
- Utiliza elementos XML como
<response>,<href>, y<status>para estructurar la información.
Ejemplo de uso:
Solicitud PROPFIND del cliente:
PROPFIND /mi-carpeta/ HTTP/1.1
Host: www.ejemplo.com
Depth: 1
Respuesta del servidor:
HTTP/1.1 207 Multi-Status
Content-Type: application/xml<?xml version=”1.0″ encoding=”utf-8″ ?>
<multistatus xmlns=”DAV:”>
<response>
<href>/mi-carpeta/archivo1</href>
<propstat>
<prop>
<displayname>archivo1</displayname>
</prop>
<status>HTTP/1.1 200 OK</status>
</propstat>
</response>
<response>
<href>/mi-carpeta/archivo2</href>
<propstat>
<prop>
<displayname>archivo2</displayname>
</prop>
<status>HTTP/1.1 404 Not Found</status>
</propstat>
</response>
</multistatus>
El código HTTP 207 Multi-Status es utilizado en el contexto de WebDAV para devolver una respuesta que incluye múltiples códigos de estado para diferentes recursos. Esto permite que el cliente entienda cómo cada recurso individual fue afectado por la solicitud.
El código de respuesta HTTP 208 Already Reported es específico del protocolo WebDAV (Extensiones para Autoría y Versionado Distribuido Basado en la Web). Este código se utiliza en un elemento de respuesta DAV: propstat para evitar enumerar repetidamente los miembros internos de colecciones de enlace múltiples.
Explicación:
Propósito: Indicar que los miembros de una colección (por ejemplo, archivos en un directorio) ya se han enumerado en una respuesta anterior, evitando así duplicar la información.
Uso común:
- Operaciones WebDAV: Utilizado en respuestas a solicitudes PROPFIND y otras solicitudes WebDAV que implican la enumeración de recursos en colecciones.
- Prevención de duplicados: Es útil para evitar la redundancia cuando un recurso ya ha sido listado anteriormente en el mismo conjunto de resultados de una operación.
Formato de la respuesta:
- Se utiliza dentro de una respuesta
207 Multi-Statusen documentos XML que enumeran varios recursos y sus propiedades. - El código 208 indica que el recurso ya fue reportado anteriormente en el mismo conjunto de respuestas.
- Se utiliza dentro de una respuesta
Ejemplo de uso:
Solicitud PROPFIND del cliente:
PROPFIND /mi-carpeta/ HTTP/1.1
Host: www.ejemplo.com
Depth: 1
Respuesta del servidor:
HTTP/1.1 207 Multi-Status
Content-Type: application/xml<?xml version=”1.0″ encoding=”utf-8″ ?>
<multistatus xmlns=”DAV:”>
<response>
<href>/mi-carpeta/archivo1</href>
<propstat>
<prop>
<displayname>archivo1</displayname>
</prop>
<status>HTTP/1.1 200 OK</status>
</propstat>
</response>
<response>
<href>/mi-carpeta/archivo2</href>
<propstat>
<prop>
<displayname>archivo2</displayname>
</prop>
<status>HTTP/1.1 208 Already Reported</status>
</propstat>
</response>
</multistatus>
El código HTTP 208 Already Reported se utiliza en el contexto de WebDAV para indicar que los miembros de una colección ya han sido enumerados previamente en una respuesta anterior, evitando así la duplicación de información en el mismo conjunto de respuestas.
El código de respuesta HTTP 214 Transformation Applied no es parte del conjunto estándar de códigos de estado HTTP definidos por la IETF. Sin embargo, existe una referencia a este código en el contexto de extensiones a HTTP, específicamente en el RFC 4918, que trata sobre WebDAV, pero incluso allí, el código 214 no es un código estándar.
A pesar de ello, podemos ofrecer una interpretación basada en el nombre “Transformation Applied”:
Propósito: El código sugiere que una transformación ha sido aplicada a la respuesta. Esto podría implicar que el servidor ha modificado el contenido de alguna manera antes de enviarlo al cliente.
Uso hipotético:
- Transformaciones de contenido: Podría ser utilizado para indicar que el contenido solicitado ha sido alterado, por ejemplo, comprimido, redimensionado, traducido, o de otra manera transformado antes de ser devuelto al cliente.
- Intermediarios o proxies: Podría aplicarse en situaciones donde un proxy o un servidor intermedio modifica el contenido antes de entregarlo al cliente final.
Sin embargo, dado que este código no es parte de los estándares oficiales HTTP, su uso no está formalmente definido y podría variar dependiendo de implementaciones específicas y no estándar.
En general, para aplicaciones y servicios que se adhieren a los estándares oficiales de HTTP, es importante utilizar los códigos de estado definidos en la especificación oficial para asegurar la interoperabilidad y comprensión adecuada entre clientes y servidores.
Si estás trabajando con un sistema específico que utiliza este código, sería recomendable consultar la documentación del sistema o del software en cuestión para obtener una comprensión precisa de cómo y cuándo se utiliza el código 214 Transformation Applied.
El código de respuesta HTTP 226 IM Used es parte del protocolo HTTP/1.1 y se define en el RFC 3229, relacionado con el uso de métodos de actualización de instancias (Instance Manipulations, IM).
Explicación:
Propósito: El código 226 IM Used indica que el servidor ha cumplido con una solicitud GET para el recurso, y que la respuesta es el resultado de una o más manipulaciones de instancias aplicadas a la versión actual de la instancia.
Uso común:
- Eficiencia en transferencias: Es utilizado para mejorar la eficiencia de la transferencia de datos, permitiendo que el servidor envíe solo los cambios (deltas) desde una versión conocida del recurso, en lugar de enviar el recurso completo.
- Metodología: Esto se logra a través de manipulaciones de instancias especificadas en el encabezado
IMde la solicitud. Los clientes pueden utilizar esto para sincronizar sus copias del recurso con el servidor de manera eficiente.
Contexto del uso:
- Actualizaciones incrementales: Por ejemplo, en aplicaciones donde los recursos cambian frecuentemente, y los clientes ya tienen una copia del recurso, este método permite enviar solo las diferencias, lo que puede reducir significativamente el uso de ancho de banda y el tiempo de transferencia.
Ejemplo de uso:
Solicitud del cliente:
GET /mi-recurso HTTP/1.1
Host: www.ejemplo.com
IM: delta
Respuesta del servidor:
HTTP/1.1 226 IM Used
Content-Type: application/json
IM: delta{
“cambios”: [
{“op”: “replace”, “path”: “/nombre”, “value”: “Nuevo Nombre”},
{“op”: “add”, “path”: “/atributos/nuevo_atributo”, “value”: “valor”}
]
}
El código HTTP 226 IM Used indica que el servidor ha procesado la solicitud y ha aplicado una o más manipulaciones de instancias al recurso antes de devolverlo. Esto es útil para reducir la cantidad de datos transferidos al permitir que solo se envíen las diferencias desde una versión conocida del recurso.
Familia del 300 (Redirecciones)
El código de respuesta HTTP 300 Multiple Choices indica que la solicitud tiene más de una posible respuesta y el usuario o el agente del usuario (como un navegador web) debe elegir una de ellas. El servidor puede proporcionar varias opciones para que el cliente seleccione la más adecuada.
Explicación:
Propósito: Informar al cliente de que hay múltiples representaciones del recurso solicitado y permitirle elegir una. Esto es útil en casos donde un recurso tiene diferentes formatos o versiones.
Uso común:
- Diferentes formatos: Un recurso puede estar disponible en varios formatos, como JSON, XML, o HTML, y el servidor proporciona estas opciones para que el cliente elija.
- Variantes de idioma: Un recurso puede tener versiones en diferentes idiomas, y el cliente puede seleccionar el idioma preferido.
Contenido de la respuesta:
- Lista de opciones: La respuesta generalmente incluye una lista de enlaces a las diferentes opciones disponibles.
- Encabezado
Location: Puede incluir un encabezadoLocationcon una lista de URI que representan las opciones.
Ejemplo de uso:
Solicitud del cliente:
GET /mi-recurso HTTP/1.1
Host: www.ejemplo.com
Respuesta del servidor:
HTTP/1.1 300 Multiple Choices
Content-Type: text/html<html>
<head>
<title>Multiple Choices</title>
</head>
<body>
<h1>Multiple Choices</h1>
<ul>
<li><a href=”/mi-recurso.json”>/mi-recurso.json</a> (JSON)</li>
<li><a href=”/mi-recurso.xml”>/mi-recurso.xml</a> (XML)</li>
<li><a href=”/mi-recurso.html”>/mi-recurso.html</a> (HTML)</li>
</ul>
</body>
</html>
El código HTTP 300 Multiple Choices indica que hay múltiples posibles respuestas para la solicitud y que el cliente debe elegir cuál de ellas quiere utilizar. La respuesta del servidor proporciona las opciones disponibles para que el cliente haga una selección.
El código de respuesta HTTP 301 Moved Permanently indica que el recurso solicitado ha sido movido de forma permanente a una nueva URL. Esto significa que todas las futuras solicitudes para ese recurso deben realizarse utilizando la nueva URL proporcionada.
Explicación:
Propósito: Informar al cliente de que el recurso solicitado ya no está disponible en la URL actual y que ha sido trasladado permanentemente a una nueva URL. El cliente debe actualizar sus enlaces y marcadores para apuntar a la nueva ubicación.
Uso común:
- Redireccionamiento permanente: Se utiliza cuando se cambia permanentemente la estructura de URLs de un sitio web. Por ejemplo, si se cambia el dominio de un sitio web o se reorganizan las rutas de acceso a los recursos.
- SEO: Ayuda a mantener el ranking de un sitio web en los motores de búsqueda, transfiriendo el valor del enlace (link juice) de la URL antigua a la nueva.
Contenido de la respuesta:
- Encabezado
Location: La respuesta incluye un encabezadoLocationque contiene la nueva URL a la que se debe redirigir el cliente. - Opcionalmente, un cuerpo: Aunque no es obligatorio, la respuesta puede incluir un cuerpo con un mensaje que informe al usuario sobre la redirección.
- Encabezado
Ejemplo de uso:
Solicitud del cliente:
GET /antigua-ruta HTTP/1.1
Host: www.ejemplo.com
Respuesta del servidor:
HTTP/1.1 301 Moved Permanently
Location: http://www.ejemplo.com/nueva-ruta
Content-Type: text/html<html>
<head>
<title>301 Moved Permanently</title>
</head>
<body>
<h1>El recurso ha sido movido permanentemente</h1>
<p>La nueva URL es <a href=”http://www.ejemplo.com/nueva-ruta”>http://www.ejemplo.com/nueva-ruta</a></p>
</body>
</html>
El código HTTP 301 Moved Permanently indica que el recurso solicitado ha sido trasladado de manera permanente a una nueva URL y proporciona esa URL en el encabezado Location. Los clientes y motores de búsqueda deben actualizar sus referencias a la URL antigua para utilizar la nueva URL en el futuro.
El código de respuesta HTTP 302 Found indica que el recurso solicitado se encuentra temporalmente en una URL diferente. Esto significa que el cliente debe seguir utilizando la URL original para futuras solicitudes, ya que la redirección a la nueva URL es solo temporal.
Explicación:
Propósito: Informar al cliente de que el recurso solicitado se encuentra temporalmente en una ubicación diferente y que debe seguir la redirección proporcionada en la respuesta. La URL original debe seguir siendo utilizada para futuras solicitudes.
Uso común:
- Redireccionamiento temporal: Se utiliza cuando se desea redirigir temporalmente a los usuarios a una nueva URL, por ejemplo, durante el mantenimiento del sitio o para pruebas A/B.
- Movimientos temporales: Para situaciones en las que los recursos se han movido temporalmente a otra ubicación, pero se espera que regresen a su ubicación original.
Contenido de la respuesta:
- Encabezado
Location: La respuesta incluye un encabezadoLocationque contiene la URL a la que se debe redirigir el cliente temporalmente. - Opcionalmente, un cuerpo: Aunque no es obligatorio, la respuesta puede incluir un cuerpo con un mensaje que informe al usuario sobre la redirección.
- Encabezado
Ejemplo de uso:
Solicitud del cliente:
GET /ruta-original HTTP/1.1
Host: www.ejemplo.com
Respuesta del servidor:
HTTP/1.1 302 Found
Location: http://www.ejemplo.com/ruta-temporal
Content-Type: text/html<html>
<head>
<title>302 Found</title>
</head>
<body>
<h1>El recurso se ha movido temporalmente</h1>
<p>Visita la URL temporal: <a href=”http://www.ejemplo.com/ruta-temporal”>http://www.ejemplo.com/ruta-temporal</a></p>
</body>
</html>
El código HTTP 302 Found indica que el recurso solicitado se encuentra temporalmente en una URL diferente y proporciona esa URL en el encabezado Location. El cliente debe seguir la redirección temporalmente pero continuar utilizando la URL original para futuras solicitudes.
El código de respuesta HTTP 303 See Other indica que el recurso solicitado se encuentra en una URL diferente y debe ser recuperado utilizando una solicitud GET a esa URL. Este código se utiliza para redireccionar al cliente a una URL diferente, típicamente después de que una solicitud POST ha sido procesada, y se espera que el cliente recupere la información desde la nueva URL utilizando una solicitud GET.
Explicación:
Propósito: Informar al cliente de que el recurso solicitado se encuentra en una URL diferente y debe ser recuperado usando una solicitud GET. Es útil para redirecciones después de operaciones que no son seguras (como POST) y donde la respuesta debe ser recuperada con un GET.
Uso común:
- Redireccionamiento después de un POST: Después de procesar un formulario o una operación que cambia el estado del servidor, el servidor puede redirigir al cliente a una nueva página (por ejemplo, una página de confirmación) usando una solicitud GET.
- Prevención de reenvíos de formularios: Ayuda a evitar que los formularios sean reenviados si el usuario refresca la página después de enviar un formulario.
Contenido de la respuesta:
- Encabezado
Location: La respuesta incluye un encabezadoLocationque contiene la URL a la que se debe redirigir el cliente. - Opcionalmente, un cuerpo: Aunque no es obligatorio, la respuesta puede incluir un cuerpo con un mensaje que informe al usuario sobre la redirección.
- Encabezado
Ejemplo de uso:
Solicitud POST del cliente:
POST /submit-form HTTP/1.1
Host: www.ejemplo.com
Content-Type: application/x-www-form-urlencodednombre=Juan&apellido=Pérez
Respuesta del servidor:
HTTP/1.1 303 See Other
Location: http://www.ejemplo.com/confirmacion
Content-Type: text/html<html>
<head>
<title>303 See Other</title>
</head>
<body>
<h1>Formulario enviado</h1>
<p>Redirigiendo a la página de confirmación…</p>
</body>
</html>
El código HTTP 303 See Other indica que el recurso solicitado se encuentra en una URL diferente y debe ser accedido mediante una solicitud GET a esa URL. Este código es especialmente útil después de solicitudes POST para redirigir al cliente a una nueva página sin riesgo de reenvío de formularios.
El código de respuesta HTTP 304 Not Modified indica que el recurso solicitado no ha sido modificado desde la última vez que fue accedido. Como resultado, no es necesario que el servidor envíe de nuevo el contenido del recurso, ya que el cliente puede utilizar la versión almacenada en su caché.
Aquí hay una explicación más detallada:
Propósito: Informar al cliente de que el recurso solicitado no ha cambiado desde la última vez que lo solicitó, permitiendo que el cliente utilice su copia en caché en lugar de volver a descargar el recurso completo. Esto reduce el uso de ancho de banda y mejora el rendimiento.
Uso común:
- Control de caché: Se utiliza junto con encabezados de control de caché como
If-Modified-SinceoIf-None-Match, donde el cliente envía una solicitud condicional para verificar si el recurso ha cambiado. - Eficiencia: Ayuda a mejorar la eficiencia de la red y la velocidad de carga de páginas web al evitar transferencias innecesarias de datos.
- Control de caché: Se utiliza junto con encabezados de control de caché como
Encabezados relacionados:
If-Modified-Since: El cliente envía este encabezado con la fecha de la última vez que el recurso fue modificado. Si el recurso no ha cambiado desde esa fecha, el servidor responde con 304 Not Modified.If-None-Match: El cliente envía este encabezado con el valor de una entidad-tag (ETag). Si el ETag coincide con el valor del recurso actual en el servidor, se devuelve 304 Not Modified.
Ejemplo de uso:
Solicitud del cliente con encabezado condicional:
GET /mi-recurso HTTP/1.1 Host: www.ejemplo.com If-Modified-Since: Wed, 21 Oct 2020 07:28:00 GMT
Respuesta del servidor indicando que el recurso no ha cambiado:
HTTP/1.1 304 Not Modified
El código HTTP 304 Not Modified indica que el recurso solicitado no ha sido modificado desde la última vez que el cliente lo accedió. Esto permite que el cliente utilice su copia en caché del recurso, mejorando la eficiencia y el rendimiento al evitar transferencias de datos innecesarias.
El código de respuesta HTTP 305 Use Proxy indica que el recurso solicitado debe ser accedido a través de un proxy especificado. Este código ha sido declarado obsoleto debido a preocupaciones de seguridad y ya no es ampliamente utilizado.
Explicación:
Propósito: Informar al cliente de que debe usar un proxy específico para acceder al recurso solicitado. La dirección del proxy se proporciona en el encabezado
Locationde la respuesta.Uso común:
- Redireccionamiento a través de un proxy: Indicar al cliente que necesita pasar su solicitud a través de un proxy específico para acceder al recurso. Esto podría haber sido utilizado para implementar controles de acceso o para redirigir el tráfico a través de un punto de control de red.
- Declarado obsoleto: Debido a problemas de seguridad y la posibilidad de exposición no intencionada de detalles de configuración del proxy, el uso de este código de estado ha sido desaconsejado y la mayoría de los navegadores modernos lo han dejado de soportar.
Contenido de la respuesta:
- Encabezado
Location: La respuesta incluye un encabezadoLocationque contiene la URL del proxy que debe ser utilizado.
- Encabezado
Ejemplo de uso (aunque es obsoleto y no se recomienda):
Solicitud del cliente:
GET /recurso HTTP/1.1
Host: www.ejemplo.com
Respuesta del servidor:
HTTP/1.1 305 Use Proxy
Location: http://proxy.ejemplo.com:8080
El código HTTP 305 Use Proxy indica que el cliente debe usar un proxy específico para acceder al recurso solicitado. Sin embargo, debido a preocupaciones de seguridad, este código ha sido declarado obsoleto y su uso ya no es recomendado ni soportado por la mayoría de los navegadores modernos.
El código de respuesta HTTP 307 Temporary Redirect indica que el recurso solicitado se encuentra temporalmente en una URL diferente y que el cliente debe realizar una nueva solicitud a esa URL utilizando el mismo método HTTP. A diferencia del código 302 Found, el código 307 garantiza que el método y el cuerpo de la solicitud original se mantendrán en la redirección.
Explicación:
Propósito: Informar al cliente de que el recurso solicitado se encuentra temporalmente en una URL diferente y que debe realizar una nueva solicitud a esa URL utilizando el mismo método HTTP que la solicitud original. Es útil para redirecciones temporales donde se quiere preservar el método original (GET, POST, etc.).
Uso común:
- Redireccionamiento temporal: Utilizado cuando se desea redirigir temporalmente a los usuarios a una nueva URL sin cambiar el método de solicitud.
- Preservación del método: Asegura que las solicitudes POST no se conviertan en solicitudes GET, lo cual puede ser importante para mantener la integridad de los datos y la intención de la solicitud original.
Contenido de la respuesta:
- Encabezado
Location: La respuesta incluye un encabezadoLocationque contiene la URL a la que se debe redirigir el cliente temporalmente. - Opcionalmente, un cuerpo: Aunque no es obligatorio, la respuesta puede incluir un cuerpo con un mensaje que informe al usuario sobre la redirección.
- Encabezado
Ejemplo de uso:
Solicitud del cliente:
POST /submit-form HTTP/1.1
Host: www.ejemplo.com
Content-Type: application/x-www-form-urlencodednombre=Juan&apellido=Pérez
Respuesta del servidor:
HTTP/1.1 307 Temporary Redirect
Location: http://www.ejemplo.com/formulario-temporal
Content-Type: text/html<html>
<head>
<title>307 Temporary Redirect</title>
</head>
<body>
<h1>Formulario enviado</h1>
<p>Redirigiendo temporalmente a la nueva URL…</p>
</body>
</html>
El código HTTP 307 Temporary Redirect indica que el recurso solicitado se encuentra temporalmente en una URL diferente y que el cliente debe seguir la redirección utilizando el mismo método HTTP que la solicitud original. Este código es especialmente útil para redirecciones temporales donde es importante preservar el método de la solicitud original.
El código de respuesta HTTP 308 Permanent Redirect indica que el recurso solicitado ha sido movido permanentemente a una nueva URL y que el cliente debe utilizar esa nueva URL para todas las solicitudes futuras. A diferencia del código 301 Moved Permanently, el código 308 garantiza que el método y el cuerpo de la solicitud original se mantendrán en la redirección.
Explicación:
Propósito: Informar al cliente de que el recurso solicitado se ha trasladado de forma permanente a una nueva URL y que debe actualizar sus enlaces y marcadores para utilizar la nueva URL en futuras solicitudes. También asegura que el método de solicitud original (GET, POST, etc.) se mantenga.
Uso común:
- Redireccionamiento permanente: Utilizado cuando un recurso ha sido movido de manera definitiva a una nueva ubicación.
- Preservación del método: Asegura que las solicitudes POST no se conviertan en solicitudes GET, lo cual puede ser importante para mantener la integridad de los datos y la intención de la solicitud original.
Contenido de la respuesta:
- Encabezado
Location: La respuesta incluye un encabezadoLocationque contiene la URL a la que se debe redirigir el cliente permanentemente. - Opcionalmente, un cuerpo: Aunque no es obligatorio, la respuesta puede incluir un cuerpo con un mensaje que informe al usuario sobre la redirección.
- Encabezado
Ejemplo de uso:
Solicitud del cliente:
POST /submit-form HTTP/1.1
Host: www.ejemplo.com
Content-Type: application/x-www-form-urlencodednombre=Juan&apellido=Pérez
Respuesta del servidor:
HTTP/1.1 308 Permanent Redirect
Location: http://www.ejemplo.com/nueva-ubicacion
Content-Type: text/html<html>
<head>
<title>308 Permanent Redirect</title>
</head>
<body>
<h1>Recurso movido permanentemente</h1>
<p>La nueva URL es <a href=”http://www.ejemplo.com/nueva-ubicacion”>http://www.ejemplo.com/nueva-ubicacion</a></p>
</body>
</html>
El código HTTP 308 Permanent Redirect indica que el recurso solicitado ha sido movido permanentemente a una nueva URL y que el cliente debe utilizar esa URL para futuras solicitudes, manteniendo el método de solicitud original. Este código es especialmente útil para redirecciones permanentes donde es importante preservar el método de la solicitud original.
Familia del 400 (Errores del Cliente)
El código de respuesta HTTP 400 Bad Request indica que el servidor no puede o no procesará la solicitud debido a un error del cliente. Este error puede deberse a una sintaxis incorrecta, una solicitud mal formada o datos inválidos enviados en la solicitud.
Explicación:
Propósito: Informar al cliente de que la solicitud no se puede procesar debido a un problema con los datos enviados por el cliente. Esto puede incluir errores en la sintaxis, parámetros incorrectos o datos no válidos.
Uso común:
- Sintaxis incorrecta: La solicitud contiene errores de sintaxis y el servidor no puede interpretarla.
- Datos inválidos: Los datos enviados en la solicitud no cumplen con los requisitos del servidor.
- Parámetros faltantes: La solicitud no incluye todos los parámetros necesarios o los parámetros proporcionados son incorrectos.
Contenido de la respuesta:
- Mensaje de error: La respuesta puede incluir un mensaje que explique la naturaleza del error, aunque no es obligatorio.
- Detalles del error: En aplicaciones más complejas, la respuesta puede incluir detalles adicionales para ayudar al cliente a corregir la solicitud.
Ejemplo de uso:
Solicitud del cliente con error de sintaxis:
GET /mi-recurso HTTP/1.1
Host: www.ejemplo.com
Content-Type: application/x-www-form-urlencodednombre=Juan&apellido
Respuesta del servidor:
HTTP/1.1 400 Bad Request
Content-Type: text/html<html>
<head>
<title>400 Bad Request</title>
</head>
<body>
<h1>Solicitud Incorrecta</h1>
<p>La solicitud no se pudo procesar debido a un error de sintaxis.</p>
</body>
</html>
El código HTTP 400 Bad Request indica que la solicitud no se puede procesar debido a un problema con los datos enviados por el cliente. Este código es utilizado para señalar errores en la sintaxis, parámetros faltantes o datos no válidos, y puede incluir un mensaje de error que ayude al cliente a corregir la solicitud.
El código de respuesta HTTP 401 Unauthorized indica que la solicitud no ha sido aplicada porque carece de credenciales de autenticación válidas para el recurso solicitado. En otras palabras, el cliente debe autenticarse para obtener la respuesta solicitada.
Explicación:
Propósito: Informar al cliente de que la solicitud no puede proceder porque no ha proporcionado las credenciales de autenticación necesarias o las credenciales proporcionadas no son válidas.
Uso común:
- Autenticación requerida: Se utiliza cuando un recurso requiere autenticación y el cliente no ha proporcionado ninguna credencial.
- Credenciales inválidas: Se usa también cuando las credenciales proporcionadas son incorrectas o han expirado.
Contenido de la respuesta:
- Encabezado
WWW-Authenticate: La respuesta incluye un encabezadoWWW-Authenticateque especifica el método de autenticación que debe utilizar el cliente para obtener acceso al recurso. Por ejemplo, podría indicar que el cliente debe proporcionar un nombre de usuario y una contraseña, un token, o algún otro tipo de credencial.
- Encabezado
Ejemplo de uso:
Solicitud del cliente sin autenticación:
GET /recurso-protegido HTTP/1.1
Host: www.ejemplo.com
Respuesta del servidor:
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Basic realm=”Acceso a recursos protegidos”
Content-Type: text/html<html>
<head>
<title>401 Unauthorized</title>
</head>
<body>
<h1>Autenticación Requerida</h1>
<p>Debe autenticarse para acceder a este recurso.</p>
</body>
</html>
El código HTTP 401 Unauthorized indica que la solicitud no puede ser procesada porque el cliente no ha proporcionado credenciales de autenticación válidas. La respuesta del servidor incluye el encabezado WWW-Authenticate, que especifica cómo debe autenticarse el cliente para acceder al recurso solicitado.
El código de respuesta HTTP 402 Payment Required es un código de estado reservado para uso futuro. No se utiliza actualmente en las aplicaciones y servicios web convencionales. Su propósito original era indicar que el acceso al recurso solicitado requiere un pago, pero no se ha estandarizado ni implementado ampliamente.
Explicación:
Propósito previsto: Informar al cliente de que la solicitud no puede ser procesada hasta que se haya realizado un pago. Este código fue reservado con la intención de ser utilizado en situaciones donde el acceso a ciertos recursos o servicios requiere un pago previo.
Uso común:
- Actualmente no en uso: No hay una implementación estándar para este código en las aplicaciones web actuales. No es utilizado por los principales navegadores ni por las APIs convencionales.
- Aplicaciones futuras: Podría ser utilizado en el futuro para servicios que requieren pago, como suscripciones, servicios premium, acceso a contenido pago, etc.
Contenido de la respuesta:
- Personalización del proveedor: Dado que no hay un estándar actual, cualquier implementación del código 402 sería específica del proveedor y podría incluir información sobre cómo realizar el pago, enlaces a portales de pago, etc.
Ejemplo de uso (hipotético):
Solicitud del cliente para un recurso premium:
GET /contenido-premium HTTP/1.1
Host: www.ejemplo.com
Respuesta del servidor (hipotética):
HTTP/1.1 402 Payment Required
Content-Type: text/html<html>
<head>
<title>402 Payment Required</title>
</head>
<body>
<h1>Pago Requerido</h1>
<p>Para acceder a este contenido, debe realizar un pago. Visite <a href=”http://www.ejemplo.com/pago”>nuestro portal de pagos</a> para completar la transacción.</p>
</body>
</html>
El código HTTP 402 Payment Required está reservado para uso futuro y no se utiliza en las aplicaciones web convencionales. Su propósito previsto es indicar que se requiere un pago para acceder al recurso solicitado, pero actualmente no hay una implementación estándar para este código.
El código de respuesta HTTP 403 Forbidden indica que el servidor ha comprendido la solicitud, pero se niega a autorizarla. A diferencia del código 401 Unauthorized, que implica que la falta de credenciales o credenciales inválidas, el código 403 indica que el servidor entiende quién es el cliente, pero el acceso al recurso está prohibido por algún motivo.
Explicación:
Propósito: Informar al cliente de que, aunque la solicitud ha sido comprendida y no requiere autenticación adicional, el servidor se niega a cumplirla debido a restricciones de acceso.
Uso común:
- Permisos insuficientes: El cliente no tiene los permisos necesarios para acceder al recurso. Por ejemplo, un usuario sin privilegios de administrador intenta acceder a una página de administración.
- Recursos protegidos: Acceso a recursos que están explícitamente prohibidos por configuraciones del servidor, políticas de seguridad, o restricciones de acceso definidas.
- Bloqueo de IP: El acceso está bloqueado debido a políticas de control de acceso basadas en la dirección IP del cliente.
Contenido de la respuesta:
- Mensaje de error: La respuesta puede incluir un mensaje que explique la razón de la prohibición, aunque no es obligatorio.
- Detalles adicionales: En algunos casos, la respuesta puede proporcionar detalles adicionales sobre cómo obtener acceso o quién contactar para más información.
Ejemplo de uso:
Solicitud del cliente sin permisos suficientes:
GET /admin HTTP/1.1
Host: www.ejemplo.com
Respuesta del servidor:
HTTP/1.1 403 Forbidden
Content-Type: text/html<html>
<head>
<title>403 Forbidden</title>
</head>
<body>
<h1>Acceso Denegado</h1>
<p>No tiene permisos para acceder a este recurso.</p>
</body>
</html>
El código HTTP 403 Forbidden indica que el servidor ha comprendido la solicitud pero se niega a autorizarla debido a restricciones de acceso. Esto puede deberse a permisos insuficientes, políticas de seguridad, o configuraciones específicas del servidor que prohíben el acceso al recurso solicitado.
El código de respuesta HTTP 404 Not Found indica que el servidor no puede encontrar el recurso solicitado. Esto significa que el servidor no pudo encontrar una página o archivo correspondiente a la URL solicitada por el cliente.
Explicación:
Propósito: Informar al cliente de que el recurso solicitado no está disponible en el servidor. Esto puede deberse a que la URL es incorrecta, el recurso ha sido eliminado, o nunca existió.
Uso común:
- URL incorrecta: El cliente ha ingresado una URL que no coincide con ningún recurso en el servidor.
- Recurso eliminado: El recurso previamente disponible ha sido eliminado o movido a otra ubicación.
- Error tipográfico: El cliente ha cometido un error tipográfico al ingresar la URL.
Contenido de la respuesta:
- Página de error personalizada: Muchos sitios web tienen páginas de error 404 personalizadas que proporcionan información adicional, enlaces útiles, o una búsqueda para ayudar al usuario a encontrar lo que está buscando.
- Mensaje básico de error: En ausencia de una página personalizada, la respuesta puede simplemente incluir un mensaje básico indicando que la página no fue encontrada.
Ejemplo de uso:
Solicitud del cliente para un recurso inexistente:
GET /pagina-inexistente HTTP/1.1
Host: www.ejemplo.com
Respuesta del servidor:
HTTP/1.1 404 Not Found
Content-Type: text/html<html>
<head>
<title>404 Not Found</title>
</head>
<body>
<h1>404 No Encontrado</h1>
<p>La página que está buscando no existe.</p>
</body>
</html>
El código HTTP 404 Not Found indica que el servidor no pudo encontrar el recurso solicitado. Este código se utiliza para señalar que la URL proporcionada por el cliente no corresponde a ningún recurso disponible en el servidor, y la respuesta puede incluir una página de error que ayude al usuario a navegar o entender el problema.
El código de respuesta HTTP 405 Method Not Allowed indica que el método especificado en la solicitud es conocido por el servidor, pero no está permitido para el recurso solicitado. Esto significa que el servidor reconoce el método HTTP (como GET, POST, PUT, DELETE, etc.) pero no permite su uso en la URL especificada.
Explicación:
Propósito: Informar al cliente de que el método HTTP utilizado en la solicitud no está permitido para el recurso especificado. Esto puede deberse a restricciones del servidor o a la configuración del recurso.
Uso común:
- Restricciones del recurso: Un recurso puede estar configurado para aceptar solo ciertos métodos. Por ejemplo, una API puede permitir GET y POST, pero no DELETE.
- Restricciones del servidor: El servidor puede tener políticas que limiten los métodos permitidos en ciertas rutas.
Contenido de la respuesta:
- Encabezado
Allow: La respuesta debe incluir un encabezadoAllowque enumera los métodos HTTP permitidos para el recurso solicitado. - Mensaje de error: La respuesta puede incluir un mensaje que explique el error, aunque no es obligatorio.
- Encabezado
Ejemplo de uso:
Solicitud del cliente con método no permitido:
DELETE /recurso HTTP/1.1
Host: www.ejemplo.com
Respuesta del servidor:
HTTP/1.1 405 Method Not Allowed
Allow: GET, POST
Content-Type: text/html<html>
<head>
<title>405 Method Not Allowed</title>
</head>
<body>
<h1>Método No Permitido</h1>
<p>El método DELETE no está permitido para este recurso. Los métodos permitidos son GET y POST.</p>
</body>
</html>
El código HTTP 405 Method Not Allowed indica que el método HTTP utilizado en la solicitud no está permitido para el recurso especificado. La respuesta debe incluir un encabezado Allow que enumera los métodos permitidos y puede incluir un mensaje de error que explique la situación al cliente.
El código de respuesta HTTP 406 Not Acceptable indica que el servidor no puede generar una respuesta que sea aceptable según los encabezados Accept enviados en la solicitud. En otras palabras, el servidor no puede satisfacer las restricciones de contenido definidas por el cliente.
Explicación:
Propósito: Informar al cliente de que el servidor no puede proporcionar una respuesta en ninguno de los formatos aceptados indicados en los encabezados
Acceptde la solicitud. Esto puede incluir tipos de contenido, codificaciones, idiomas, etc.Uso común:
- Negociación de contenido: Cuando el cliente especifica que solo acepta ciertos tipos de contenido (por ejemplo, solo JSON o XML) y el servidor no puede devolver una respuesta en esos formatos.
- Restricciones del cliente: El cliente puede definir en los encabezados de la solicitud las características que acepta para la respuesta, como
Accept,Accept-Encoding,Accept-Language, yAccept-Charset.
Contenido de la respuesta:
- Mensaje de error: La respuesta puede incluir un mensaje que explique por qué no se puede cumplir con la solicitud en los formatos aceptables. Esto puede ayudar al cliente a modificar su solicitud.
- Opciones alternativas: En algunos casos, la respuesta puede incluir información sobre los formatos disponibles que el servidor puede proporcionar.
Ejemplo de uso:
Solicitud del cliente con restricciones de contenido:
GET /recurso HTTP/1.1
Host: www.ejemplo.com
Accept: application/json
Respuesta del servidor:
HTTP/1.1 406 Not Acceptable
Content-Type: text/html<html>
<head>
<title>406 Not Acceptable</title>
</head>
<body>
<h1>Contenido No Aceptable</h1>
<p>El servidor no puede generar una respuesta en el formato solicitado (application/json). Intente modificar su solicitud para aceptar un formato diferente.</p>
</body>
</html>
El código HTTP 406 Not Acceptable indica que el servidor no puede proporcionar una respuesta que cumpla con las restricciones de contenido especificadas por el cliente en los encabezados Accept. La respuesta puede incluir un mensaje explicativo y, en algunos casos, información sobre los formatos alternativos disponibles.
El código de respuesta HTTP 407 Proxy Authentication Required indica que el cliente debe autenticarse con un proxy antes de que la solicitud pueda ser procesada. Es similar al código 401 Unauthorized, pero se aplica específicamente a la autenticación requerida por un servidor proxy.
Explicación:
Propósito: Informar al cliente de que debe autenticarse con el proxy para que la solicitud pueda continuar. Esto implica que el proxy necesita credenciales de autenticación antes de permitir el acceso al recurso solicitado.
Uso común:
- Autenticación del proxy: Utilizado cuando el cliente está detrás de un proxy que requiere autenticación. Esto es común en entornos corporativos o redes que utilizan proxies para gestionar y controlar el acceso a Internet.
- Configuración de red: El servidor proxy exige que el cliente proporcione credenciales válidas antes de permitir el tráfico a través de él.
Contenido de la respuesta:
- Encabezado
Proxy-Authenticate: La respuesta incluye un encabezadoProxy-Authenticateque especifica el método de autenticación que debe utilizar el cliente para autenticarse con el proxy. - Mensaje de error: La respuesta puede incluir un mensaje que explique que se requiere autenticación con el proxy.
- Encabezado
Ejemplo de uso:
Solicitud del cliente sin autenticación del proxy:
GET /recurso HTTP/1.1
Host: www.ejemplo.com
Respuesta del proxy:
HTTP/1.1 407 Proxy Authentication Required
Proxy-Authenticate: Basic realm=”Proxy”
Content-Type: text/html<html>
<head>
<title>407 Proxy Authentication Required</title>
</head>
<body>
<h1>Autenticación del Proxy Requerida</h1>
<p>Debe autenticarse con el proxy para acceder al recurso solicitado.</p>
</body>
</html>
El código HTTP 407 Proxy Authentication Required indica que el cliente debe autenticarse con el proxy antes de que la solicitud pueda ser procesada. La respuesta incluye el encabezado Proxy-Authenticate, que especifica el método de autenticación requerido por el proxy.
El código de respuesta HTTP 408 Request Timeout indica que el servidor no recibió una solicitud completa del cliente dentro del tiempo que estaba preparado para esperar. Este código se envía cuando el servidor ha esperado una cierta cantidad de tiempo por la solicitud completa y no la ha recibido.
Explicación:
Propósito: Informar al cliente de que el servidor cerró la conexión debido a que la solicitud no se completó en un tiempo razonable. Esto puede ocurrir si la conexión es lenta o si el cliente deja de enviar datos antes de completar la solicitud.
Uso común:
- Conexiones lentas: Cuando el cliente no puede enviar la solicitud completa en el tiempo esperado debido a una conexión lenta o interrupciones.
- Tiempo de espera del servidor: El servidor tiene configurado un tiempo de espera específico y la solicitud del cliente no se completó dentro de ese tiempo.
Contenido de la respuesta:
- Mensaje de error: La respuesta puede incluir un mensaje que explique que el tiempo de espera para la solicitud ha expirado. No es obligatorio, pero puede proporcionar más contexto al cliente.
Ejemplo de uso:
Solicitud del cliente que no se completa a tiempo:
GET /recurso HTTP/1.1
Host: www.ejemplo.com
(esperando datos adicionales que nunca llegan)
Respuesta del servidor:
HTTP/1.1 408 Request Timeout
Content-Type: text/html<html>
<head>
<title>408 Request Timeout</title>
</head>
<body>
<h1>Tiempo de Espera de la Solicitud Expirado</h1>
<p>El servidor no recibió la solicitud completa dentro del tiempo esperado.</p>
</body>
</html>
El código HTTP 408 Request Timeout indica que el servidor cerró la conexión porque no recibió una solicitud completa del cliente dentro del tiempo que estaba preparado para esperar. Esto puede deberse a conexiones lentas, interrupciones, o cualquier otra razón que impida que el cliente complete la solicitud en el tiempo esperado por el servidor.
El código de respuesta HTTP 409 Conflict indica que la solicitud no pudo ser completada debido a un conflicto con el estado actual del recurso. Este código de estado se utiliza cuando el servidor tiene conflictos con el recurso que está intentando modificar o actualizar.
Explicación:
Propósito: Informar al cliente de que la solicitud no se puede completar debido a un conflicto con el estado actual del recurso en el servidor. Esto puede ocurrir en situaciones donde hay una modificación concurrente del recurso o si los datos proporcionados en la solicitud causan un conflicto.
Uso común:
- Conflictos de edición: Cuando múltiples usuarios intentan modificar el mismo recurso al mismo tiempo y las modificaciones causan conflictos.
- Conflictos de estado: Cuando la operación solicitada no puede ser completada debido al estado actual del recurso, como una solicitud para actualizar un recurso con datos desactualizados.
Contenido de la respuesta:
- Mensaje de error: La respuesta puede incluir un mensaje que describa la naturaleza del conflicto y, si es posible, sugerir una forma de resolverlo.
- Detalles del conflicto: En aplicaciones más complejas, la respuesta puede proporcionar detalles adicionales sobre cómo resolver el conflicto, como versiones del recurso, sugerencias de actualización, etc.
Ejemplo de uso:
Solicitud del cliente para actualizar un recurso con conflicto:
PUT /recurso HTTP/1.1
Host: www.ejemplo.com
Content-Type: application/json{
“id”: 1,
“nombre”: “Recurso Actualizado”,
“version”: 1
}
Respuesta del servidor indicando conflicto:
HTTP/1.1 409 Conflict
Content-Type: application/json{
“mensaje”: “Conflicto al intentar actualizar el recurso.”,
“detalles”: “El recurso ha sido modificado por otro usuario. Por favor, obtenga la última versión del recurso e intente de nuevo.”
}
El código HTTP 409 Conflict indica que la solicitud no se puede completar debido a un conflicto con el estado actual del recurso en el servidor. Este código se utiliza en situaciones donde hay conflictos de edición concurrente o estado del recurso, y la respuesta puede proporcionar detalles sobre la naturaleza del conflicto y sugerencias para resolverlo.
El código de respuesta HTTP 410 Gone indica que el recurso solicitado ya no está disponible en el servidor y no hay una dirección de reenvío conocida. Este estado se usa cuando el servidor sabe, por algún motivo interno, que el recurso solicitado ya no estará disponible en el futuro.
Explicación:
Propósito: Informar al cliente de que el recurso solicitado ha sido permanentemente eliminado del servidor y no hay una nueva URL a la que se haya movido. Esto difiere del código 404 Not Found, que solo indica que el recurso no está disponible en el momento actual, sin hacer suposiciones sobre su permanencia.
Uso común:
- Eliminación permanente: Cuando un recurso ha sido eliminado permanentemente y no se espera que se vuelva a poner en línea.
- Contenido expirado: Para indicar que el contenido previamente disponible ya no está y no será reemplazado, como artículos, documentos, o páginas específicas que han sido retiradas.
Contenido de la respuesta:
- Mensaje de error: La respuesta puede incluir un mensaje que explique que el recurso ha sido eliminado y no está disponible. No es obligatorio, pero puede proporcionar más contexto al cliente.
Ejemplo de uso:
Solicitud del cliente para un recurso eliminado:
GET /recurso-antiguo HTTP/1.1
Host: www.ejemplo.com
Respuesta del servidor indicando que el recurso ha sido eliminado:
HTTP/1.1 410 Gone
Content-Type: text/html<html>
<head>
<title>410 Gone</title>
</head>
<body>
<h1>Recurso Eliminado</h1>
<p>El recurso solicitado ya no está disponible en este servidor y no hay una dirección de reenvío conocida.</p>
</body>
</html>
El código HTTP 410 Gone indica que el recurso solicitado ha sido permanentemente eliminado del servidor y no se proporcionará una nueva URL para acceder a él. Este código se utiliza para señalar la eliminación definitiva de un recurso y ayuda a los clientes y motores de búsqueda a entender que no deben seguir solicitando ese recurso en el futuro.
El código de respuesta HTTP 411 Length Required indica que el servidor rechaza la solicitud porque no incluye el encabezado Content-Length, que es necesario para procesar la solicitud. Este código de estado se utiliza cuando el servidor requiere conocer la longitud del cuerpo de la solicitud antes de poder procesarla adecuadamente.
Explicación:
Propósito: Informar al cliente de que la solicitud no se puede procesar porque falta el encabezado
Content-Length, que especifica la longitud del cuerpo de la solicitud.Uso común:
- Requisito del servidor: Algunos servidores o aplicaciones necesitan saber la longitud exacta del contenido que están recibiendo para poder manejarlo adecuadamente. Esto es especialmente importante para solicitudes que incluyen un cuerpo de datos, como POST o PUT.
Contenido de la respuesta:
- Mensaje de error: La respuesta puede incluir un mensaje que explique que se requiere el encabezado
Content-Lengthpara procesar la solicitud.
- Mensaje de error: La respuesta puede incluir un mensaje que explique que se requiere el encabezado
Ejemplo de uso:
Solicitud del cliente sin el encabezado Content-Length:
POST /upload HTTP/1.1
Host: www.ejemplo.com
Content-Type: application/json{
“nombre”: “Juan Pérez”,
“archivo”: “datos.bin”
}
Respuesta del servidor indicando que falta el encabezado Content-Length:
HTTP/1.1 411 Length Required
Content-Type: text/html<html>
<head>
<title>411 Length Required</title>
</head>
<body>
<h1>Longitud Requerida</h1>
<p>El encabezado `Content-Length` es necesario para procesar esta solicitud.</p>
</body>
</html>
El código HTTP 411 Length Required indica que la solicitud no puede ser procesada porque falta el encabezado Content-Length, que especifica la longitud del cuerpo de la solicitud. Este código se utiliza para asegurar que el servidor tiene la información necesaria para manejar adecuadamente el contenido de la solicitud.
El código de respuesta HTTP 412 Precondition Failed indica que una o más de las condiciones preestablecidas en los encabezados de la solicitud del cliente evaluaron como falsas cuando se intentó aplicarlas en el servidor. Esto significa que el servidor no cumplirá con la solicitud porque no se cumplen las condiciones especificadas.
Explicación:
Propósito: Informar al cliente de que la solicitud no puede ser completada porque no se cumplen las condiciones especificadas en los encabezados condicionales de la solicitud, como
If-Match,If-None-Match,If-Modified-Since,If-Unmodified-Since, oIf-Range.Uso común:
- Encabezados condicionales: El cliente puede utilizar encabezados condicionales para realizar solicitudes que solo deben cumplirse si se cumplen ciertas condiciones. Por ejemplo, asegurarse de que un recurso no ha sido modificado desde una fecha específica o que coincide con un ETag determinado.
- Control de concurrencia: Utilizado para evitar conflictos en escenarios donde múltiples clientes podrían estar intentando modificar un recurso al mismo tiempo.
Contenido de la respuesta:
- Mensaje de error: La respuesta puede incluir un mensaje que explique por qué las condiciones no se cumplieron, aunque no es obligatorio.
Ejemplo de uso:
Solicitud del cliente con condiciones:
PUT /recurso HTTP/1.1
Host: www.ejemplo.com
If-Match: “etag12345”
Content-Type: application/json{
“nombre”: “Recurso Actualizado”
}
Respuesta del servidor indicando que la condición falló:
HTTP/1.1 412 Precondition Failed
Content-Type: text/html<html>
<head>
<title>412 Precondition Failed</title>
</head>
<body>
<h1>Precondición Fallida</h1>
<p>La condición especificada en el encabezado `If-Match` no se cumplió.</p>
</body>
</html>
El código HTTP 412 Precondition Failed indica que la solicitud no puede ser completada porque una o más condiciones especificadas en los encabezados de la solicitud no se cumplieron. Este código se utiliza para manejar solicitudes condicionales y evitar conflictos en situaciones donde se aplican reglas de concurrencia o control de versiones.
El código de respuesta HTTP 413 Payload Too Large indica que la solicitud del cliente es más grande de lo que el servidor está dispuesto o es capaz de procesar. Esto significa que el servidor ha rechazado la solicitud debido a su tamaño excesivo.
Explicación:
Propósito: Informar al cliente de que la solicitud no puede ser procesada porque el tamaño del cuerpo de la solicitud es mayor de lo que el servidor está dispuesto o es capaz de manejar.
Uso común:
- Tamaño de carga excesivo: Cuando un cliente intenta cargar un archivo o enviar datos que superan el límite de tamaño permitido por el servidor.
- Configuraciones del servidor: El servidor puede tener configuraciones que limitan el tamaño máximo permitido para el cuerpo de las solicitudes.
Contenido de la respuesta:
- Mensaje de error: La respuesta puede incluir un mensaje que explique que el tamaño del cuerpo de la solicitud es demasiado grande. No es obligatorio, pero puede proporcionar más contexto al cliente.
- Encabezado
Retry-After(opcional): En algunos casos, el servidor puede incluir este encabezado para indicar cuándo el cliente puede intentar nuevamente la solicitud o proporcionar instrucciones adicionales.
Ejemplo de uso:
Solicitud del cliente con un cuerpo de solicitud demasiado grande:
POST /subir-archivo HTTP/1.1
Host: www.ejemplo.com
Content-Type: application/octet-stream
Content-Length: 52428800[datos del archivo]
Respuesta del servidor indicando que la carga es demasiado grande:
HTTP/1.1 413 Payload Too Large
Content-Type: text/html<html>
<head>
<title>413 Payload Too Large</title>
</head>
<body>
<h1>La carga es demasiado grande</h1>
<p>El servidor no puede procesar la solicitud porque el cuerpo de la solicitud es demasiado grande.</p>
</body>
</html>
El código HTTP 413 Payload Too Large indica que el servidor ha rechazado la solicitud porque el cuerpo de la solicitud es demasiado grande para ser procesado. Este código se utiliza para señalar que el tamaño de los datos enviados excede los límites permitidos por el servidor, y la respuesta puede incluir un mensaje explicativo y, opcionalmente, un encabezado Retry-After para proporcionar instrucciones adicionales al cliente.
El código de respuesta HTTP 414 URI Too Long indica que la URI (Uniform Resource Identifier) proporcionada en la solicitud es demasiado larga para que el servidor la procese. Este código se utiliza cuando la longitud de la URI excede el límite que el servidor está dispuesto a manejar.
Explicación:
Propósito: Informar al cliente de que la URI de la solicitud es demasiado larga y no puede ser procesada por el servidor. Esto puede suceder si la URI contiene demasiada información, como parámetros de consulta excesivamente largos.
Uso común:
- URIs generadas automáticamente: URIs que son generadas por sistemas automáticamente y que contienen grandes cantidades de datos o parámetros.
- Errores de configuración: Cuando una aplicación cliente construye una URI con una longitud que excede los límites del servidor.
Contenido de la respuesta:
- Mensaje de error: La respuesta puede incluir un mensaje que explique que la URI es demasiado larga. No es obligatorio, pero puede proporcionar más contexto al cliente.
Ejemplo de uso:
Solicitud del cliente con una URI demasiado larga:
GET /buscar?parametro1=valor1¶metro2=valor2&…¶metro1000=valor1000 HTTP/1.1
Host: www.ejemplo.com
Respuesta del servidor indicando que la URI es demasiado larga:
HTTP/1.1 414 URI Too Long
Content-Type: text/html<html>
<head>
<title>414 URI Too Long</title>
</head>
<body>
<h1>URI Demasiado Larga</h1>
<p>La URI proporcionada en la solicitud es demasiado larga para ser procesada por el servidor.</p>
</body>
</html>
El código HTTP 414 URI Too Long indica que la URI proporcionada en la solicitud es demasiado larga para ser procesada por el servidor. Este código se utiliza cuando la longitud de la URI excede los límites permitidos por el servidor, y la respuesta puede incluir un mensaje explicativo para ayudar al cliente a entender y corregir el problema.
El código de respuesta HTTP 415 Unsupported Media Type indica que el servidor rechaza la solicitud porque el tipo de medio (o tipo de contenido) del cuerpo de la solicitud no es compatible o no es soportado por el servidor. Esto significa que el servidor no puede procesar la solicitud debido a que el tipo de contenido no es adecuado para el recurso solicitado.
Explicación:
Propósito: Informar al cliente de que el servidor no puede procesar la solicitud porque el tipo de medio del cuerpo de la solicitud no es compatible con el recurso solicitado.
Uso común:
- Tipo de contenido no soportado: Cuando el cliente envía datos en un formato que el servidor no reconoce o no soporta. Por ejemplo, enviar datos en formato XML a un endpoint que solo acepta JSON.
- Encabezado
Content-Typeincorrecto: Cuando el encabezadoContent-Typeespecifica un tipo de medio que el servidor no puede manejar.
Contenido de la respuesta:
- Mensaje de error: La respuesta puede incluir un mensaje que explique que el tipo de contenido no es soportado por el servidor. No es obligatorio, pero puede proporcionar más contexto al cliente.
Ejemplo de uso:
Solicitud del cliente con un tipo de contenido no soportado:
POST /api/recurso HTTP/1.1
Host: www.ejemplo.com
Content-Type: application/xml<recurso>
<nombre>Ejemplo</nombre>
</recurso>
Respuesta del servidor indicando que el tipo de contenido no es soportado:
HTTP/1.1 415 Unsupported Media Type
Content-Type: text/html<html>
<head>
<title>415 Unsupported Media Type</title>
</head>
<body>
<h1>Tipo de Contenido No Soportado</h1>
<p>El servidor no puede procesar la solicitud porque el tipo de contenido ‘application/xml’ no es soportado.</p>
</body>
</html>
El código HTTP 415 Unsupported Media Type indica que el servidor no puede procesar la solicitud debido a que el tipo de medio del cuerpo de la solicitud no es compatible con el recurso solicitado. La respuesta puede incluir un mensaje explicativo para ayudar al cliente a entender y corregir el problema.
El código de respuesta HTTP 416 Range Not Satisfiable indica que el servidor no puede cumplir con la solicitud de rango especificada en el encabezado Range del cliente. Esto sucede cuando el rango solicitado no es válido para el tamaño del recurso solicitado.
Explicación:
Propósito: Informar al cliente de que el servidor no puede proporcionar la parte del recurso solicitada porque el rango especificado no es válido.
Uso común:
- Rango fuera de los límites: El cliente solicita una porción del recurso que está fuera del rango disponible. Por ejemplo, si el recurso tiene 1000 bytes y el cliente solicita bytes desde el 1500 al 2000.
- Recursos inexistentes: Cuando el recurso solicitado no existe y, por lo tanto, no se puede cumplir con ningún rango solicitado.
Contenido de la respuesta:
- Encabezado
Content-Range: El servidor debe incluir un encabezadoContent-Rangeen la respuesta, indicando el tamaño del recurso actual o el rango válido. Este encabezado tiene la formaContent-Range: bytes */[tamaño-del-recurso], donde[tamaño-del-recurso]es el tamaño total del recurso.
- Encabezado
Ejemplo de uso:
Solicitud del cliente con un rango inválido:
GET /archivo.txt HTTP/1.1
Host: www.ejemplo.com
Range: bytes=1500-2000
Respuesta del servidor indicando que el rango no es válido:
HTTP/1.1 416 Range Not Satisfiable
Content-Range: bytes */1000
Content-Type: text/html<html>
<head>
<title>416 Range Not Satisfiable</title>
</head>
<body>
<h1>Rango No Satisfactorio</h1>
<p>El rango solicitado no es válido para el tamaño del recurso solicitado.</p>
</body>
</html>
El código HTTP 416 Range Not Satisfiable indica que el servidor no puede cumplir con la solicitud de rango especificada por el cliente porque el rango solicitado no es válido para el tamaño del recurso. La respuesta incluye un encabezado Content-Range que proporciona información sobre el tamaño del recurso y puede ayudar al cliente a ajustar su solicitud.
El código de respuesta HTTP 417 Expectation Failed indica que el servidor no puede cumplir con los requisitos especificados en el campo de encabezado Expect de la solicitud. Este código se utiliza cuando el cliente envía una solicitud con un encabezado Expect que el servidor no puede satisfacer.
Explicación:
Propósito: Informar al cliente de que el servidor no puede cumplir con la expectativa indicada en el encabezado
Expectde la solicitud.Uso común:
- Encabezado
Expect: El encabezadoExpectse utiliza en las solicitudes HTTP para indicar que el cliente espera que el servidor realice alguna acción específica antes de proceder con el resto de la solicitud. Por ejemplo,Expect: 100-continueindica que el cliente espera recibir una respuesta provisional100 Continuedel servidor antes de enviar el cuerpo de la solicitud. - Expectativas no cumplidas: Si el servidor no puede satisfacer la expectativa indicada en el encabezado, responde con el código 417 Expectation Failed.
- Encabezado
Contenido de la respuesta:
- Mensaje de error: La respuesta puede incluir un mensaje que explique que la expectativa especificada en el encabezado
Expectno puede ser cumplida por el servidor.
- Mensaje de error: La respuesta puede incluir un mensaje que explique que la expectativa especificada en el encabezado
Ejemplo de uso:
Solicitud del cliente con un encabezado Expect:
POST /api/recurso HTTP/1.1
Host: www.ejemplo.com
Expect: 100-continue
Content-Type: application/json
Content-Length: 348{
“nombre”: “Juan Pérez”,
“correo”: “[email protected]”
}
Respuesta del servidor indicando que la expectativa no puede ser cumplida:
HTTP/1.1 417 Expectation Failed
Content-Type: text/html<html>
<head>
<title>417 Expectation Failed</title>
</head>
<body>
<h1>Expectativa No Cumplida</h1>
<p>El servidor no puede cumplir con la expectativa especificada en el encabezado `Expect`.</p>
</body>
</html>
El código HTTP 417 Expectation Failed indica que el servidor no puede cumplir con los requisitos especificados en el campo de encabezado Expect de la solicitud. Este código se utiliza para manejar expectativas que el servidor no puede satisfacer y proporciona al cliente una indicación de que debe ajustar su solicitud.
El código de respuesta HTTP 418 I’m a Teapot es una referencia humorística a la especificación de “Hyper Text Coffee Pot Control Protocol” (HTCPCP), que fue definida en el RFC 2324 en 1998 como una broma del Día de los Inocentes (April Fools’ Day). Este código de estado no es utilizado en aplicaciones HTTP reales, pero se ha mantenido como una curiosidad histórica en el mundo de la tecnología.
Aquí hay una explicación más detallada:
Propósito: Indicar que el servidor es una tetera y, por lo tanto, no puede cumplir con la solicitud de preparación de café. Es una broma y no tiene un propósito práctico en aplicaciones HTTP reales.
Uso común:
- Humor: Usado como una broma o un guiño a la especificación del RFC 2324.
- Ejemplos de aprendizaje: A veces se menciona en ejemplos de aprendizaje y discusiones técnicas para ilustrar cómo funcionan los códigos de estado HTTP.
Contenido de la respuesta:
- Mensaje humorístico: La respuesta puede incluir un mensaje que explique la naturaleza humorística del código.
Ejemplo de uso (humorístico):
Solicitud del cliente (en el contexto del RFC 2324):
BREW /coffee HTTP/1.1
Host: www.ejemplo.com
Respuesta del servidor (como tetera):
HTTP/1.1 418 I’m a Teapot
Content-Type: text/html<html>
<head>
<title>418 I’m a Teapot</title>
</head>
<body>
<h1>Soy una Tetera</h1>
<p>No puedo preparar café porque soy una tetera.</p>
</body>
</html>
El código HTTP 418 I’m a Teapot es una respuesta humorística definida en el RFC 2324 como parte de una broma del Día de los Inocentes. No se utiliza en aplicaciones HTTP reales y no tiene un propósito práctico, pero se mantiene como una curiosidad histórica en el ámbito de los protocolos web.
El código de respuesta HTTP 420 Enhance Your Calm es un código no estándar que fue utilizado por la API de Twitter para indicar que el cliente está siendo rate limited, es decir, que ha enviado demasiadas solicitudes en un corto período de tiempo y debe calmarse y reducir la velocidad de sus solicitudes. Este código no forma parte de la especificación oficial de HTTP y ha sido reemplazado por el código estándar 429 Too Many Requests en la API de Twitter.
Explicación:
Propósito: Informar al cliente de que ha excedido el límite de solicitudes permitidas en un período de tiempo y debe reducir la frecuencia de sus solicitudes para evitar ser bloqueado.
Uso común:
- Rate limiting: Utilizado para controlar la carga en servidores y APIs al limitar la cantidad de solicitudes que un cliente puede hacer en un período de tiempo específico.
- API de Twitter: Fue utilizado específicamente por la API de Twitter antes de ser reemplazado por el código estándar 429 Too Many Requests.
Contenido de la respuesta:
- Mensaje de error: La respuesta puede incluir un mensaje que explique que el cliente debe reducir la frecuencia de sus solicitudes.
- Encabezado
Retry-After(opcional): En algunos casos, la respuesta puede incluir este encabezado para indicar cuándo el cliente puede volver a intentar la solicitud.
Ejemplo de uso (API de Twitter, obsoleto):
Solicitud del cliente que excede el límite de solicitudes:
GET /api/tweets HTTP/1.1
Host: api.twitter.com
Respuesta del servidor indicando que el límite de solicitudes ha sido excedido:
HTTP/1.1 420 Enhance Your Calm
Content-Type: application/json{
“error”: “You are being rate limited. Enhance your calm and try again later.”
}
El código HTTP 420 Enhance Your Calm fue utilizado por la API de Twitter para indicar que el cliente estaba siendo rate limited y debía reducir la frecuencia de sus solicitudes. Este código no es parte de la especificación oficial de HTTP y ha sido reemplazado por el código estándar 429 Too Many Requests en la API de Twitter.
El código de respuesta HTTP 421 Misdirected Request indica que la solicitud fue enviada a un servidor que no puede producir una respuesta adecuada. Esto puede suceder cuando la solicitud está dirigida a un servidor que no tiene la autoridad para acceder al recurso solicitado o no está configurado para manejar esa solicitud específica.
Explicación:
Propósito: Informar al cliente de que la solicitud fue enviada a un servidor incorrecto, y que el servidor no puede procesar la solicitud porque no está autorizado o configurado para manejarla.
Uso común:
- Configuraciones de servidor: Cuando la solicitud se envía a un servidor que no tiene la capacidad o configuración necesaria para responder a la solicitud, por ejemplo, en un entorno con múltiples servidores donde uno de ellos no es el adecuado para la solicitud específica.
- Redirección incorrecta: Puede ocurrir en sistemas con balanceadores de carga o proxies donde la solicitud se dirige a un servidor que no es capaz de manejarla correctamente.
Contenido de la respuesta:
- Mensaje de error: La respuesta puede incluir un mensaje que explique que la solicitud fue enviada al servidor incorrecto.
- Posibles soluciones: Aunque no es obligatorio, el servidor puede proporcionar información adicional sobre a dónde debe ser dirigida la solicitud o cómo corregir el problema.
Ejemplo de uso:
Solicitud del cliente a un servidor incorrecto:
GET /recurso HTTP/1.1
Host: www.ejemplo.com
Respuesta del servidor indicando que la solicitud fue mal dirigida:
HTTP/1.1 421 Misdirected Request
Content-Type: text/html<html>
<head>
<title>421 Misdirected Request</title>
</head>
<body>
<h1>Solicitud Mal Dirigida</h1>
<p>La solicitud fue enviada a un servidor que no puede producir una respuesta adecuada.</p>
</body>
</html>
El código HTTP 421 Misdirected Request indica que la solicitud fue enviada a un servidor que no está autorizado o configurado para manejarla. Este código se utiliza para señalar que la solicitud necesita ser dirigida a un servidor diferente que pueda responder adecuadamente a la misma.
El código de respuesta HTTP 422 Unprocessable Entity indica que el servidor entiende el tipo de contenido de la solicitud y la sintaxis de la solicitud es correcta, pero no puede procesar las instrucciones contenidas debido a errores semánticos. Este código se usa principalmente en aplicaciones web que siguen el protocolo WebDAV (Extensiones para Autoría y Versionado Distribuido Basado en la Web), pero también puede ser usado en otros contextos.
Explicación:
Propósito: Informar al cliente de que la solicitud fue recibida y entendida, pero el servidor no puede procesarla debido a problemas semánticos en el contenido de la solicitud.
Uso común:
- Errores de validación: Cuando el contenido de la solicitud tiene errores de validación, como campos obligatorios que faltan, valores fuera de rango, o formatos incorrectos.
- Inconsistencias semánticas: Cuando los datos proporcionados en la solicitud son internamente inconsistentes o no tienen sentido lógico según las reglas del servidor.
Contenido de la respuesta:
- Mensaje de error: La respuesta generalmente incluye un mensaje que describe el error y puede proporcionar detalles sobre qué partes de la solicitud causaron el problema.
- Detalles de validación: En algunos casos, la respuesta puede incluir detalles específicos de los errores de validación para que el cliente pueda corregirlos.
Ejemplo de uso:
Solicitud del cliente con datos inválidos:
POST /usuarios HTTP/1.1
Host: www.ejemplo.com
Content-Type: application/json{
“nombre”: “Juan”,
“correo”: “correo invalido”
}
Respuesta del servidor indicando que hay errores en los datos:
HTTP/1.1 422 Unprocessable Entity
Content-Type: application/json{
“errores”: {
“correo”: “El formato del correo electrónico no es válido.”
}
}
El código HTTP 422 Unprocessable Entity indica que el servidor no puede procesar la solicitud debido a errores semánticos en el contenido de la solicitud. La respuesta generalmente incluye un mensaje de error que describe el problema y puede proporcionar detalles específicos para ayudar al cliente a corregir los errores y reenviar la solicitud.
El código de respuesta HTTP 423 Locked indica que el recurso al que se está intentando acceder está bloqueado y no puede ser modificado. Este código se utiliza principalmente en el contexto del protocolo WebDAV (Extensiones para Autoría y Versionado Distribuido Basado en la Web), que es una extensión de HTTP para la manipulación y gestión de archivos en servidores web.
Explicación:
Propósito: Informar al cliente de que el recurso solicitado está bloqueado y no puede ser modificado hasta que se elimine el bloqueo. Esto ayuda a evitar conflictos durante operaciones concurrentes sobre el mismo recurso.
Uso común:
- Operaciones WebDAV: Utilizado cuando un recurso está bloqueado por una operación WebDAV para evitar modificaciones concurrentes.
- Control de concurrencia: Ayuda a gestionar y coordinar el acceso a recursos para evitar que múltiples clientes realicen cambios simultáneos que puedan causar inconsistencias o conflictos.
Contenido de la respuesta:
- Mensaje de error: La respuesta puede incluir un mensaje que explique que el recurso está bloqueado y puede proporcionar detalles sobre el bloqueo, aunque no es obligatorio.
Ejemplo de uso:
Solicitud del cliente para modificar un recurso bloqueado:
PROPPATCH /archivo HTTP/1.1
Host: www.ejemplo.com
Content-Type: application/xml<?xml version=”1.0″ encoding=”utf-8″ ?>
<propertyupdate xmlns=”DAV:”>
<set>
<prop>
<author>Juan Pérez</author>
</prop>
</set>
</propertyupdate>
Respuesta del servidor indicando que el recurso está bloqueado:
HTTP/1.1 423 Locked
Content-Type: text/html<html>
<head>
<title>423 Locked</title>
</head>
<body>
<h1>Recurso Bloqueado</h1>
<p>El recurso solicitado está bloqueado y no puede ser modificado.</p>
</body>
</html>
El código HTTP 423 Locked indica que el recurso solicitado está bloqueado y no puede ser modificado hasta que se elimine el bloqueo. Este código se utiliza principalmente en el contexto de WebDAV para gestionar el acceso concurrente a recursos y evitar conflictos.
El código de respuesta HTTP 424 Failed Dependency indica que la solicitud falló debido a la falla de una solicitud previa, de la cual dependía. Este código se utiliza principalmente en el contexto del protocolo WebDAV (Extensiones para Autoría y Versionado Distribuido Basado en la Web), que extiende HTTP para la manipulación y gestión de archivos en servidores web.
Aquí hay una explicación más detallada:
Propósito: Informar al cliente de que la solicitud no se puede completar porque depende de otra operación que ha fallado. Esta dependencia fallida impide que la solicitud actual sea procesada con éxito.
Uso común:
- Operaciones WebDAV: Utilizado cuando una solicitud en una secuencia de operaciones WebDAV depende de la finalización exitosa de una solicitud anterior que ha fallado.
- Transacciones dependientes: Cuando las operaciones son interdependientes, y el fallo de una impide la ejecución de las siguientes.
Contenido de la respuesta:
- Mensaje de error: La respuesta puede incluir un mensaje que explique que la solicitud falló debido a una dependencia fallida, aunque no es obligatorio.
Ejemplo de uso:
- Solicitud del cliente que depende de otra operación:
- Supongamos que un cliente hace una solicitud para bloquear un recurso (LOCK) y luego intenta hacer una solicitud PROPPATCH que depende de que el recurso esté bloqueado.Primera solicitud (LOCK) que falla:
LOCK /archivo HTTP/1.1
Host: www.ejemplo.com
Content-Type: application/xml<?xml version=”1.0″ encoding=”utf-8″ ?>
<lockinfo xmlns=”DAV:”>
<lockscope><exclusive/></lockscope>
<locktype><write/></locktype>
<owner>
<href>http://www.ejemplo.com/usuario</href>
</owner>
</lockinfo>
Respuesta del servidor a la solicitud LOCK:
HTTP/1.1 403 Forbidden
Content-Type: text/html<html>
<head>
<title>403 Forbidden</title>
</head>
<body>
<h1>Acceso Prohibido</h1>
<p>No tiene permiso para bloquear este recurso.</p>
</body>
</html>
Segunda solicitud (PROPPATCH) que falla debido a la dependencia:
PROPPATCH /archivo HTTP/1.1
Host: www.ejemplo.com
Content-Type: application/xml<?xml version=”1.0″ encoding=”utf-8″ ?>
<propertyupdate xmlns=”DAV:”>
<set>
<prop>
<author>Juan Pérez</author>
</prop>
</set>
</propertyupdate>
Respuesta del servidor indicando que la solicitud falló debido a la dependencia:
HTTP/1.1 424 Failed Dependency
Content-Type: text/html<html>
<head>
<title>424 Failed Dependency</title>
</head>
<body>
<h1>Dependencia Fallida</h1>
<p>La solicitud no se pudo completar porque depende de otra solicitud que falló.</p>
</body>
</html>
El código HTTP 424 Failed Dependency indica que la solicitud falló debido a la falla de una solicitud anterior de la cual dependía. Este código se utiliza principalmente en el contexto de WebDAV para gestionar operaciones interdependientes y transacciones que requieren la finalización exitosa de solicitudes previas.
El código de respuesta HTTP 425 Too Early indica que el servidor no está dispuesto a procesar la solicitud porque podría ser repetida. Esto es parte de una estrategia para evitar que las solicitudes se repitan prematuramente en contextos donde se utilizan protocolos que manejan la transmisión de datos de forma segura, como el protocolo TLS (Transport Layer Security) con la extensión 0-RTT (Zero Round Trip Time).
Explicación:
Propósito: Informar al cliente de que el servidor no puede procesar la solicitud en este momento porque es demasiado pronto, y procesarla podría tener riesgos de seguridad, como la repetición de solicitudes en escenarios donde no se ha establecido completamente una conexión segura.
Uso común:
- TLS 0-RTT: En el contexto de la extensión 0-RTT de TLS 1.3, que permite a los clientes enviar datos antes de que la conexión esté completamente establecida. Esto mejora la latencia, pero también introduce riesgos de seguridad, como los ataques de repetición.
- Seguridad: Utilizado cuando el servidor desea asegurarse de que la solicitud no sea procesada de manera prematura para evitar posibles vulnerabilidades de seguridad.
Contenido de la respuesta:
- Mensaje de error: La respuesta puede incluir un mensaje que explique que la solicitud es demasiado temprana para ser procesada, aunque no es obligatorio.
Ejemplo de uso:
Solicitud del cliente que es demasiado temprana:
POST /api/recurso HTTP/1.1
Host: www.ejemplo.com
Early-Data: 1{
“data”: “example”
}
Respuesta del servidor indicando que la solicitud es demasiado temprana:
HTTP/1.1 425 Too Early
Content-Type: text/html<html>
<head>
<title>425 Too Early</title>
</head>
<body>
<h1>Solicitud Demasiado Temprana</h1>
<p>El servidor no está dispuesto a procesar la solicitud en este momento. Por favor, intente de nuevo más tarde.</p>
</body>
</html>
El código HTTP 425 Too Early indica que el servidor no está dispuesto a procesar la solicitud porque es demasiado pronto, y hacerlo podría presentar riesgos de seguridad, especialmente en el contexto del protocolo TLS 0-RTT. Este código ayuda a prevenir la repetición prematura de solicitudes en situaciones donde aún no se ha establecido completamente una conexión segura.
El código de respuesta HTTP 426 Upgrade Required indica que el servidor se niega a procesar la solicitud utilizando el protocolo actual, pero está dispuesto a hacerlo después de que el cliente se actualice a un protocolo diferente. Este código se utiliza para indicar que el cliente debe cambiar a una versión más reciente del protocolo o a un protocolo completamente diferente para poder continuar.
Explicación:
Propósito: Informar al cliente de que debe actualizar a un protocolo diferente para que el servidor procese la solicitud. Esto puede ser necesario cuando el servidor requiere características o capacidades de una versión más reciente del protocolo que el cliente está utilizando.
Uso común:
- Actualización de protocolo: Cuando el servidor requiere que el cliente utilice un protocolo diferente, como cambiar de HTTP/1.1 a HTTP/2 o a WebSocket.
- Mejora de seguridad: Para forzar a los clientes a usar un protocolo más seguro o eficiente.
Contenido de la respuesta:
- Encabezado
Upgrade: La respuesta incluye un encabezadoUpgradeque especifica el protocolo(s) al que el cliente debe cambiar para poder continuar. - Mensaje de error: La respuesta puede incluir un mensaje que explique que se requiere una actualización del protocolo.
- Encabezado
Ejemplo de uso:
Solicitud del cliente con un protocolo no aceptado:
GET /recurso HTTP/1.1
Host: www.ejemplo.com
Respuesta del servidor indicando que se requiere una actualización del protocolo:
HTTP/1.1 426 Upgrade Required
Upgrade: HTTP/2.0
Content-Type: text/html<html>
<head>
<title>426 Upgrade Required</title>
</head>
<body>
<h1>Actualización Requerida</h1>
<p>El servidor requiere que actualice su protocolo a HTTP/2.0 para procesar esta solicitud.</p>
</body>
</html>
El código HTTP 426 Upgrade Required indica que el servidor se niega a procesar la solicitud utilizando el protocolo actual y que el cliente debe actualizar a un protocolo diferente especificado en el encabezado Upgrade para que el servidor procese la solicitud. Este código se utiliza para mejorar la compatibilidad, la seguridad o la eficiencia de las comunicaciones entre el cliente y el servidor.
El código de respuesta HTTP 428 Precondition Required indica que el servidor requiere que la solicitud sea condicional. Esto significa que el servidor quiere asegurarse de que el cliente haga la solicitud con ciertos encabezados condicionales, como If-Match, If-None-Match, If-Modified-Since, If-Unmodified-Since o If-Range.
El objetivo de este código es evitar conflictos de edición cuando múltiples usuarios están accediendo y modificando el mismo recurso simultáneamente. Se asegura de que el cliente solo realice la acción si ciertas condiciones son verdaderas.
Explicación:
Propósito:
- Evitar conflictos: Asegurar que las modificaciones al recurso se realicen solo si el recurso no ha sido modificado desde la última vez que el cliente lo vio.
- Consistencia de datos: Garantizar que el cliente tenga una copia actual del recurso antes de realizar modificaciones.
Uso común:
- Control de concurrencia optimista: Usado en APIs RESTful y sistemas donde varios clientes pueden intentar modificar el mismo recurso.
- Validaciones condicionales: Cuando es crucial que la solicitud sea procesada solo si ciertas condiciones son verdaderas para mantener la integridad de los datos.
Contenido de la respuesta:
- Mensaje de error: La respuesta puede incluir un mensaje que explique que se requiere una condición previa y puede sugerir los encabezados condicionales que el cliente debe usar.
Ejemplo de uso:
Solicitud del cliente sin encabezados condicionales:
PUT /recurso/123 HTTP/1.1
Host: www.ejemplo.com
Content-Type: application/json{
“nombre”: “Recurso Actualizado”
}
Respuesta del servidor indicando que se requiere una condición previa:
HTTP/1.1 428 Precondition Required
Content-Type: text/html<html>
<head>
<title>428 Precondition Required</title>
</head>
<body>
<h1>Precondition Required</h1>
<p>Debe realizar esta solicitud con una condición previa. Utilice un encabezado `If-Match` para asegurarse de que el recurso no ha sido modificado.</p>
</body>
</html>
El código HTTP 428 Precondition Required se utiliza para exigir que las solicitudes incluyan ciertos encabezados condicionales para evitar conflictos y asegurar la consistencia de los datos. Esto es especialmente útil en entornos donde varios clientes pueden estar accediendo y modificando el mismo recurso simultáneamente.
El código de respuesta HTTP 429 Too Many Requests indica que el cliente ha enviado demasiadas solicitudes en un periodo de tiempo dado y, por lo tanto, el servidor está rechazando la solicitud para evitar la sobrecarga. Este código se utiliza para implementar políticas de limitación de tasas (rate limiting) y proteger los recursos del servidor contra el abuso o el uso excesivo.
Explicación detallada:
Propósito:
- Rate limiting: Controlar la cantidad de solicitudes que un cliente puede hacer en un periodo de tiempo determinado para evitar la sobrecarga del servidor.
- Protección contra abuso: Prevenir el uso excesivo de los recursos del servidor por parte de un cliente, lo que podría afectar el rendimiento y la disponibilidad del servicio para otros usuarios.
Uso común:
- APIs: Utilizado por servicios de API para limitar la cantidad de solicitudes que un cliente puede hacer en un minuto, hora, día, etc.
- Servidores web: Implementado en servidores web para gestionar el tráfico y prevenir ataques de denegación de servicio (DoS).
Contenido de la respuesta:
- Mensaje de error: La respuesta generalmente incluye un mensaje que explica que se han enviado demasiadas solicitudes y puede proporcionar información sobre cuándo puede intentarlo nuevamente.
- Encabezado
Retry-After(opcional): El servidor puede incluir este encabezado para indicar cuánto tiempo debe esperar el cliente antes de volver a intentar la solicitud.
Ejemplo de uso:
Solicitud del cliente excediendo el límite de solicitudes:
GET /api/recurso HTTP/1.1
Host: www.ejemplo.com
Respuesta del servidor indicando que se ha excedido el límite de solicitudes:
HTTP/1.1 429 Too Many Requests
Content-Type: application/json
Retry-After: 3600{
“error”: “Too Many Requests”,
“message”: “Has realizado demasiadas solicitudes en un periodo corto de tiempo. Por favor, espera una hora antes de intentarlo nuevamente.”
}
El código HTTP 429 Too Many Requests se utiliza para indicar que el cliente ha excedido el número permitido de solicitudes en un periodo de tiempo específico. Este código ayuda a implementar políticas de limitación de tasas para proteger los recursos del servidor y garantizar la disponibilidad y el rendimiento del servicio para todos los usuarios. La respuesta puede incluir un encabezado Retry-After para informar al cliente cuánto tiempo debe esperar antes de intentar nuevamente.
El código de respuesta HTTP 431 Request Header Fields Too Large indica que el servidor se niega a procesar la solicitud porque uno o más campos de encabezado de la solicitud son demasiado grandes. Esto puede ocurrir si el tamaño total de los encabezados de la solicitud supera un límite que el servidor está dispuesto a aceptar, o si un único encabezado es excesivamente grande.
Explicación detallada:
Propósito:
- Protección del servidor: Evitar que los servidores sean sobrecargados con solicitudes que tienen encabezados demasiado grandes, lo cual podría afectar el rendimiento o la capacidad de manejar otras solicitudes.
- Control de tamaño: Garantizar que los encabezados de la solicitud sean de un tamaño manejable para el servidor, protegiendo contra posibles ataques o errores de configuración del cliente.
Uso común:
- Encabezados excesivos: Cuando los clientes envían solicitudes con demasiados datos en los encabezados, ya sea intencionalmente o por error.
- Configuración de límite del servidor: Los servidores pueden tener límites configurados para el tamaño máximo permitido de los encabezados de la solicitud.
Contenido de la respuesta:
- Mensaje de error: La respuesta generalmente incluye un mensaje que explica que uno o más campos de encabezado son demasiado grandes.
- Opciones de corrección: La respuesta puede sugerir al cliente cómo reducir el tamaño de los encabezados para que la solicitud sea aceptada.
Ejemplo de uso:
Solicitud del cliente con encabezados demasiado grandes:
GET /recurso HTTP/1.1
Host: www.ejemplo.com
X-Custom-Header: [un encabezado muy largo…]
…
Respuesta del servidor indicando que los campos de encabezado son demasiado grandes:
HTTP/1.1 431 Request Header Fields Too Large
Content-Type: text/html<html>
<head>
<title>431 Request Header Fields Too Large</title>
</head>
<body>
<h1>Campos de Encabezado de Solicitud Demasiado Grandes</h1>
<p>Uno o más campos de encabezado en la solicitud son demasiado grandes.</p>
</body>
</html>
El código HTTP 431 Request Header Fields Too Large se utiliza para indicar que el servidor se niega a procesar la solicitud porque uno o más campos de encabezado de la solicitud son demasiado grandes. Esto protege al servidor de ser sobrecargado por encabezados excesivamente grandes y ayuda a mantener el rendimiento y la capacidad de manejar otras solicitudes. La respuesta puede incluir un mensaje explicativo y sugerencias para reducir el tamaño de los encabezados.
El código de respuesta HTTP 444 No Response es un código no estándar específico del servidor web Nginx. Se utiliza para indicar que el servidor ha cerrado la conexión sin enviar una respuesta al cliente. Este código no está definido en los estándares oficiales HTTP y no se utiliza fuera del contexto de Nginx.
Explicación detallada:
Propósito:
- Cerrar la conexión: El código 444 se utiliza para cerrar la conexión con el cliente sin enviar ningún encabezado o cuerpo de respuesta. Esto puede ser útil para bloquear solicitudes maliciosas o innecesarias.
- Mitigar ataques: Puede ser utilizado como una medida para mitigar ciertos tipos de ataques, como ataques de denegación de servicio (DoS), donde es beneficioso simplemente cerrar la conexión sin responder.
Uso común:
- Configuración de Nginx: Especificado en la configuración del servidor Nginx para ciertas condiciones, como bloquear IPs, solicitudes específicas o comportamientos sospechosos.
- Eficiencia: Al no enviar una respuesta, el servidor ahorra recursos que de otro modo serían utilizados para procesar y enviar una respuesta completa.
Contenido de la respuesta:
- Sin respuesta: No se envía ningún contenido al cliente. El servidor simplemente cierra la conexión.
Ejemplo de uso en la configuración de Nginx:
En un archivo de configuración de Nginx, el código 444 puede ser utilizado de la siguiente manera:
server {
listen 80;
server_name www.ejemplo.com;location / {
if ($http_user_agent ~* “malicious_bot”) {
return 444;
}
proxy_pass http://backend_server;
}
}
En este ejemplo, si el agente de usuario de la solicitud coincide con “malicious_bot”, Nginx cerrará la conexión sin enviar una respuesta, utilizando el código 444.
El código HTTP 444 No Response es un código no estándar específico del servidor web Nginx, utilizado para cerrar la conexión con el cliente sin enviar una respuesta. Se utiliza comúnmente para bloquear solicitudes maliciosas o innecesarias, ahorrando recursos del servidor y mitigando ciertos tipos de ataques. Este código no está definido en los estándares oficiales HTTP y no se utiliza fuera del contexto de Nginx.
El código de respuesta HTTP 450 Blocked by Windows Parental Controls es un código no estándar que fue definido por Microsoft para indicar que el acceso al recurso solicitado ha sido bloqueado por los controles parentales de Windows. Este código no forma parte de la especificación oficial de HTTP y es específico de ciertos entornos de Windows.
Explicación detallada:
Propósito:
- Bloqueo de contenido: Indicar que el acceso a la página o recurso solicitado ha sido bloqueado debido a las restricciones establecidas por los controles parentales de Windows.
- Control parental: Ayudar a los administradores y padres a gestionar y restringir el acceso a contenido inapropiado o no deseado en dispositivos gestionados por Windows.
Uso común:
- Windows Parental Controls: Utilizado en sistemas donde los controles parentales de Windows están habilitados y se ha configurado para bloquear ciertos tipos de contenido o sitios web.
- Administración de red: Puede ser usado en entornos familiares o educativos para asegurar que los usuarios no accedan a contenido inapropiado.
Contenido de la respuesta:
- Mensaje de bloqueo: La respuesta puede incluir un mensaje que explique que el acceso ha sido bloqueado por los controles parentales de Windows, aunque esto puede variar dependiendo de la implementación específica.
Ejemplo de uso:
Supongamos que un usuario intenta acceder a un sitio web que ha sido bloqueado por los controles parentales:
Solicitud del cliente para un recurso bloqueado:
GET /sitio-bloqueado HTTP/1.1
Host: www.ejemplo.com
Respuesta indicando que el acceso ha sido bloqueado:
HTTP/1.1 450 Blocked by Windows Parental Controls
Content-Type: text/html<html>
<head>
<title>450 Blocked</title>
</head>
<body>
<h1>Acceso Bloqueado</h1>
<p>El acceso a este recurso ha sido bloqueado por los controles parentales de Windows.</p>
</body>
</html>
El código HTTP 450 Blocked by Windows Parental Controls es un código no estándar utilizado por Microsoft para indicar que el acceso a un recurso ha sido bloqueado por los controles parentales de Windows. Este código se utiliza para gestionar y restringir el acceso a contenido inapropiado o no deseado en dispositivos gestionados por Windows, y no forma parte de la especificación oficial de HTTP. La respuesta puede incluir un mensaje explicativo sobre el bloqueo.
El código de respuesta HTTP 451 Unavailable For Legal Reasons indica que el recurso solicitado no está disponible debido a restricciones legales. Esto significa que el servidor ha recibido una orden legal que le prohíbe proporcionar acceso al recurso.
Explicación detallada:
Propósito:
- Cumplimiento legal: Informar al cliente de que el recurso solicitado no puede ser proporcionado debido a razones legales, como una orden judicial o una solicitud gubernamental.
- Transparencia: Proporcionar una razón clara y específica para la indisponibilidad del recurso, en lugar de utilizar un código genérico como 403 Forbidden.
Uso común:
- Censura: Cuando un gobierno u otra entidad legal ha ordenado la censura de un sitio web o un recurso específico.
- Protección de derechos de autor: Cuando se ha ordenado la eliminación de contenido debido a violaciones de derechos de autor u otras leyes de propiedad intelectual.
Contenido de la respuesta:
- Mensaje de error: La respuesta puede incluir un mensaje que explique la razón legal por la cual el recurso no está disponible.
- Detalles adicionales: En algunos casos, la respuesta puede proporcionar detalles adicionales sobre la orden legal o la entidad que la emitió.
Ejemplo de uso:
Solicitud del cliente para un recurso bloqueado por razones legales:
GET /recurso-restringido HTTP/1.1
Host: www.ejemplo.com
Respuesta del servidor indicando que el recurso no está disponible por razones legales:
HTTP/1.1 451 Unavailable For Legal Reasons
Content-Type: text/html<html>
<head>
<title>451 Unavailable For Legal Reasons</title>
</head>
<body>
<h1>Recurso No Disponible</h1>
<p>El acceso a este recurso ha sido restringido por razones legales.</p>
<p>Motivo: Orden judicial emitida por el Tribunal de Justicia.</p>
</body>
</html>
El código HTTP 451 Unavailable For Legal Reasons indica que el recurso solicitado no está disponible debido a restricciones legales. Este código proporciona una razón específica y clara para la indisponibilidad del recurso, ayudando a los clientes a entender que el acceso ha sido restringido por razones legales, como órdenes judiciales o solicitudes gubernamentales. La respuesta puede incluir detalles adicionales sobre la orden legal o la entidad que la emitió.
El código de respuesta HTTP 497 HTTP Request Sent to HTTPS Port es un código no estándar específico del servidor web Nginx. Este código se utiliza para indicar que se ha enviado una solicitud HTTP a un puerto que normalmente está configurado para aceptar solicitudes HTTPS.
Explicación detallada:
Propósito:
- Errores de configuración de cliente: Informar al cliente de que ha intentado acceder a un puerto HTTPS utilizando el protocolo HTTP. Los puertos HTTPS están configurados para manejar tráfico cifrado mediante SSL/TLS y no pueden procesar solicitudes no cifradas adecuadamente.
- Mejora de la seguridad: Asegurarse de que las solicitudes dirigidas a puertos HTTPS sean manejadas de forma segura mediante el cifrado adecuado.
Uso común:
- Configuración de Nginx: Utilizado en servidores Nginx para manejar casos en los que las solicitudes HTTP se envían erróneamente a un puerto HTTPS.
- Redirección y corrección: A menudo se configura para redirigir automáticamente tales solicitudes al puerto correcto o para informar al usuario del error.
Contenido de la respuesta:
- Mensaje de error: La respuesta puede incluir un mensaje que explique que la solicitud HTTP fue enviada a un puerto HTTPS y proporcionar información sobre cómo corregir el error.
Ejemplo de uso:
Solicitud del cliente utilizando HTTP en un puerto HTTPS:
GET /recurso HTTP/1.1
Host: www.ejemplo.com
Respuesta del servidor Nginx indicando que la solicitud fue enviada al puerto incorrecto:
HTTP/1.1 497 HTTP Request Sent to HTTPS Port
Content-Type: text/html<html>
<head>
<title>497 HTTP Request Sent to HTTPS Port</title>
</head>
<body>
<h1>Solicitud HTTP Enviada al Puerto HTTPS</h1>
<p>Ha intentado acceder a un puerto HTTPS utilizando HTTP. Por favor, use HTTPS en su solicitud.</p>
</body>
</html>
Configuración de Nginx para manejar este error:
En la configuración de Nginx, puedes especificar cómo manejar estas solicitudes incorrectas:
server {
listen 443 ssl;
server_name www.ejemplo.com;# SSL configuration
ssl_certificate /path/to/cert.pem;
ssl_certificate_key /path/to/key.pem;error_page 497 https://$host$request_uri;
# Other configurations…
}
El código HTTP 497 HTTP Request Sent to HTTPS Port es un código no estándar específico de Nginx utilizado para indicar que se ha enviado una solicitud HTTP a un puerto configurado para HTTPS. Este código ayuda a informar al cliente del error y a asegurar que las solicitudes sean manejadas de forma segura mediante el cifrado adecuado. La respuesta puede incluir un mensaje explicativo y, en algunos casos, se puede configurar para redirigir automáticamente al cliente al puerto y protocolo correctos.
El código de respuesta HTTP 498 Invalid Token es un código no estándar específico de la API de Google para la biblioteca de JavaScript Maps. Este código se utiliza para indicar que el token de autenticación o el token de acceso proporcionado en la solicitud es inválido o ha expirado.
Explicación detallada:
Propósito:
- Autenticación fallida: Informar al cliente de que el token de autenticación o el token de acceso proporcionado no es válido. Esto puede ocurrir si el token ha expirado, es incorrecto, o ha sido revocado.
- Control de acceso: Asegurar que solo los clientes con tokens válidos puedan acceder a los recursos protegidos de la API.
Uso común:
- APIs de Google: Utilizado principalmente en el contexto de las APIs de Google, como la API de Google Maps, para manejar tokens de autenticación inválidos.
- Autenticación de API: En cualquier sistema que utilice tokens para autenticar solicitudes a una API, este código puede ser utilizado para indicar problemas con el token.
Contenido de la respuesta:
- Mensaje de error: La respuesta generalmente incluye un mensaje que explica que el token es inválido o ha expirado, proporcionando detalles adicionales para ayudar al cliente a entender y corregir el problema.
Ejemplo de uso:
Solicitud del cliente con un token inválido:
GET /maps/api/directions/json?origin=place_id:ChIJd_Y0eVIvkIARuQyDN0F1LBA&destination=place_id:ChIJ68aBlmkDdkgRXG6LUbMW6A8&key=INVALID_TOKEN HTTP/1.1
Host: maps.googleapis.com
Respuesta del servidor indicando que el token es inválido:
HTTP/1.1 498 Invalid Token
Content-Type: application/json{
“error”: {
“code”: 498,
“message”: “Invalid Token: The provided token is expired or invalid.”,
“status”: “INVALID_ARGUMENT”
}
}
El código HTTP 498 Invalid Token es un código no estándar utilizado principalmente en las APIs de Google para indicar que el token de autenticación o de acceso proporcionado en la solicitud es inválido o ha expirado. Este código ayuda a controlar el acceso a los recursos protegidos y asegura que solo los clientes con tokens válidos puedan acceder a ellos. La respuesta generalmente incluye un mensaje explicativo y detalles adicionales para ayudar al cliente a resolver el problema con el token.
El código de respuesta HTTP 499 Client Closed Request es un código no estándar específico del servidor web Nginx. Este código indica que el cliente cerró la conexión antes de que el servidor pudiera enviar una respuesta. Es utilizado por Nginx para registrar este tipo de eventos en sus logs.
Explicación detallada:
Propósito:
- Registro de eventos: Informar que el cliente ha cerrado la conexión antes de que el servidor pudiera completar la solicitud y enviar una respuesta.
- Manejo de conexiones interrumpidas: Ayudar a los administradores del servidor a entender y diagnosticar problemas relacionados con clientes que abandonan solicitudes prematuramente.
Uso común:
- Nginx: Utilizado específicamente en el servidor web Nginx para registrar en los logs cuando un cliente cierra la conexión de manera inesperada.
- Interrupciones de red: Puede ocurrir debido a problemas de red, clientes que se desconectan abruptamente, o aplicaciones que deciden cancelar la solicitud.
Contenido de la respuesta:
- Sin contenido de respuesta: Dado que el cliente ha cerrado la conexión, no se envía una respuesta al cliente. El evento se registra en los logs del servidor.
Ejemplo de uso:
Situación en la que el cliente cierra la solicitud antes de recibir la respuesta:
- Un cliente hace una solicitud a un servidor, pero cierra el navegador o se desconecta de la red antes de que el servidor pueda enviar la respuesta.
Registro del evento en los logs de Nginx:
- Nginx registra este evento con el código 499 en sus logs:
192.168.1.1 - - [15/Jul/2023:15:05:32 +0000] "GET /api/recurso HTTP/1.1" 499 0 "-" "Mozilla/5.0"
El código HTTP 499 Client Closed Request es un código no estándar utilizado por Nginx para indicar que el cliente cerró la conexión antes de que el servidor pudiera enviar una respuesta. Este código es útil para registrar y diagnosticar eventos en los que las conexiones son interrumpidas por el cliente de manera inesperada. No se envía ninguna respuesta al cliente, ya que la conexión ya ha sido cerrada.
Familia del 500 (Errores del Servidor)
El código de respuesta HTTP 500 Internal Server Error indica que el servidor encontró una condición inesperada que le impidió cumplir con la solicitud. Este es un código de error general que puede ser usado cuando el servidor no tiene una respuesta más específica para la condición que encontró.
Explicación detallada:
Propósito:
- Error genérico del servidor: Indicar que algo salió mal en el servidor, pero el servidor no puede ser más específico sobre cuál es el problema exacto.
- Condición inesperada: Señalar que el servidor encontró una situación que no sabe cómo manejar.
Uso común:
- Errores de configuración: Problemas con la configuración del servidor, errores en el código de la aplicación, o problemas con las dependencias del servidor.
- Problemas temporales: Condiciones temporales como fallos en la base de datos, tiempo de espera de servicios externos, o problemas de recursos.
Contenido de la respuesta:
- Mensaje de error: La respuesta puede incluir un mensaje que explique que se ha producido un error interno del servidor. Este mensaje puede ser genérico para evitar la divulgación de detalles del sistema.
- Detalles adicionales (opcional): En entornos de desarrollo, el servidor puede proporcionar detalles adicionales sobre el error para ayudar a los desarrolladores a diagnosticar y solucionar el problema.
Ejemplo de uso:
Solicitud del cliente que resulta en un error interno del servidor:
GET /api/recurso HTTP/1.1
Host: www.ejemplo.com
Respuesta del servidor indicando un error interno:
HTTP/1.1 500 Internal Server Error
Content-Type: text/html<html>
<head>
<title>500 Internal Server Error</title>
</head>
<body>
<h1>Error Interno del Servidor</h1>
<p>Se ha producido un error inesperado en el servidor. Por favor, intente nuevamente más tarde.</p>
</body>
</html>
El código HTTP 500 Internal Server Error indica que el servidor encontró una condición inesperada que le impidió cumplir con la solicitud. Este es un código de error genérico que se utiliza cuando el servidor no puede ser más específico sobre el problema. La respuesta puede incluir un mensaje genérico sobre el error y, en algunos casos, detalles adicionales para ayudar a diagnosticar el problema. Este código señala un fallo en el servidor que necesita ser investigado y solucionado por los administradores del sistema o los desarrolladores.
El código de respuesta HTTP 501 Not Implemented indica que el servidor no reconoce el método de solicitud o no tiene la capacidad de cumplir con la solicitud. Este código se utiliza cuando el servidor no soporta la funcionalidad requerida para cumplir con la solicitud.
Explicación detallada:
Propósito:
- Método no soportado: Informar al cliente de que el método HTTP utilizado en la solicitud no es reconocido por el servidor o no está implementado.
- Funcionalidad no disponible: Indicar que el servidor no tiene la capacidad de cumplir con la solicitud debido a la falta de la funcionalidad requerida.
Uso común:
- Métodos HTTP desconocidos: Cuando el cliente utiliza un método HTTP que el servidor no reconoce, como un método personalizado o un método que no está implementado en el servidor.
- Funcionalidad no implementada: Cuando el servidor no ha implementado la funcionalidad necesaria para procesar la solicitud, como un endpoint de una API que aún no está disponible.
Contenido de la respuesta:
- Mensaje de error: La respuesta puede incluir un mensaje que explique que el método no está implementado o que la funcionalidad no está disponible.
- Detalles adicionales (opcional): En algunos casos, la respuesta puede proporcionar información adicional sobre qué métodos son soportados o por qué la funcionalidad no está disponible.
Ejemplo de uso:
Solicitud del cliente con un método no soportado:
TRACE /api/recurso HTTP/1.1
Host: www.ejemplo.com
Respuesta del servidor indicando que el método no está implementado:
HTTP/1.1 501 Not Implemented
Content-Type: text/html<html>
<head>
<title>501 Not Implemented</title>
</head>
<body>
<h1>Método No Implementado</h1>
<p>El método HTTP TRACE no está soportado por este servidor.</p>
</body>
</html>
El código HTTP 501 Not Implemented indica que el servidor no reconoce el método de solicitud o no tiene la capacidad de cumplir con la solicitud. Este código se utiliza cuando el servidor no soporta la funcionalidad requerida para procesar la solicitud. La respuesta puede incluir un mensaje explicativo y, en algunos casos, detalles adicionales sobre los métodos soportados o la falta de funcionalidad.
El código de respuesta HTTP 502 Bad Gateway indica que un servidor actuando como una puerta de enlace o proxy recibió una respuesta inválida o inapropiada de un servidor upstream (un servidor más adelante en la cadena de comunicación). Esto significa que el servidor proxy o puerta de enlace no pudo completar la solicitud del cliente debido a un problema con el servidor backend.
Explicación detallada:
Propósito:
- Error de servidor intermedio: Informar al cliente de que el servidor proxy o puerta de enlace encontró un problema al intentar comunicarse con el servidor upstream.
- Problemas de backend: Indicar que el problema no reside en el servidor que respondió directamente al cliente, sino en otro servidor al que se dirigió la solicitud.
Uso común:
- Servidores proxy y puertas de enlace: Utilizado por servidores que actúan como intermediarios, como proxies, puertas de enlace API, y balanceadores de carga.
- Servicios distribuidos: Común en arquitecturas de microservicios y sistemas donde múltiples servicios interactúan entre sí y un fallo en la cadena puede causar un error 502.
Contenido de la respuesta:
- Mensaje de error: La respuesta puede incluir un mensaje que explique que hubo un problema al intentar comunicarse con el servidor upstream.
- Detalles adicionales (opcional): En algunos casos, la respuesta puede proporcionar información adicional sobre el problema, aunque esto no es obligatorio y depende de la configuración del servidor.
Ejemplo de uso:
Solicitud del cliente a un servidor proxy:
GET /api/recurso HTTP/1.1
Host: www.ejemplo.com
Respuesta del servidor proxy indicando un error del servidor upstream:
HTTP/1.1 502 Bad Gateway
Content-Type: text/html<html>
<head>
<title>502 Bad Gateway</title>
</head>
<body>
<h1>Bad Gateway</h1>
<p>El servidor proxy recibió una respuesta inválida del servidor upstream.</p>
</body>
</html>
El código HTTP 502 Bad Gateway indica que un servidor actuando como una puerta de enlace o proxy recibió una respuesta inválida o inapropiada de un servidor upstream. Este código se utiliza para señalar problemas de comunicación entre servidores en una arquitectura donde hay intermediarios que manejan las solicitudes del cliente. La respuesta puede incluir un mensaje explicativo sobre el problema con el servidor upstream.
El código de respuesta HTTP 503 Service Unavailable indica que el servidor no puede manejar la solicitud en ese momento debido a que está temporalmente sobrecargado o en mantenimiento. Esto significa que el servidor no está disponible temporalmente y sugiere que el cliente puede intentar la solicitud de nuevo después de algún tiempo.
Explicación detallada:
Propósito:
- Sobrecarga del servidor: Informar al cliente de que el servidor no puede procesar la solicitud debido a una sobrecarga temporal.
- Mantenimiento: Indicar que el servidor está temporalmente fuera de servicio debido a tareas de mantenimiento programadas.
Uso común:
- Servidores sobrecargados: Cuando el servidor está recibiendo más solicitudes de las que puede manejar y necesita tiempo para recuperarse.
- Mantenimiento programado: Durante períodos de mantenimiento planificado cuando el servidor no está disponible para procesar solicitudes.
Contenido de la respuesta:
- Mensaje de error: La respuesta puede incluir un mensaje que explique que el servidor no está disponible temporalmente y puede proporcionar una estimación de cuándo volverá a estar disponible.
- Encabezado
Retry-After(opcional): El servidor puede incluir un encabezadoRetry-Afterpara indicar cuánto tiempo debe esperar el cliente antes de intentar nuevamente la solicitud.
Ejemplo de uso:
Solicitud del cliente durante un período de mantenimiento:
GET /api/recurso HTTP/1.1
Host: www.ejemplo.com
Respuesta del servidor indicando que el servicio no está disponible temporalmente:
HTTP/1.1 503 Service Unavailable
Content-Type: text/html
Retry-After: 3600<html>
<head>
<title>503 Service Unavailable</title>
</head>
<body>
<h1>Servicio No Disponible</h1>
<p>El servidor está temporalmente sobrecargado o en mantenimiento. Por favor, intente nuevamente después de una hora.</p>
</body>
</html>
El código HTTP 503 Service Unavailable indica que el servidor no puede manejar la solicitud en ese momento debido a que está temporalmente sobrecargado o en mantenimiento. Este código sugiere que el cliente puede intentar la solicitud nuevamente después de un tiempo. La respuesta puede incluir un mensaje explicativo y, opcionalmente, un encabezado Retry-After para indicar cuándo el cliente debe intentar nuevamente.
El código de respuesta HTTP 504 Gateway Timeout indica que un servidor actuando como una puerta de enlace o proxy no recibió una respuesta a tiempo de un servidor upstream (un servidor más adelante en la cadena de comunicación) necesario para completar la solicitud. Esto significa que el servidor no pudo obtener una respuesta oportuna de otro servidor al que se dirigió la solicitud, resultando en un tiempo de espera.
Explicación detallada:
Propósito:
- Tiempo de espera del servidor upstream: Informar al cliente de que el servidor proxy o puerta de enlace no pudo obtener una respuesta a tiempo de otro servidor upstream.
- Problemas de conectividad: Señalar problemas de conectividad o retrasos en la respuesta del servidor upstream.
Uso común:
- Servidores proxy y puertas de enlace: Utilizado por servidores que actúan como intermediarios, como proxies, puertas de enlace API, y balanceadores de carga.
- Sistemas distribuidos: Común en arquitecturas de microservicios y sistemas donde múltiples servicios interactúan entre sí y pueden experimentar tiempos de espera.
Contenido de la respuesta:
- Mensaje de error: La respuesta puede incluir un mensaje que explique que hubo un tiempo de espera al intentar comunicarse con el servidor upstream.
- Detalles adicionales (opcional): En algunos casos, la respuesta puede proporcionar información adicional sobre el problema, aunque esto no es obligatorio y depende de la configuración del servidor.
Ejemplo de uso:
Solicitud del cliente a un servidor proxy:
GET /api/recurso HTTP/1.1
Host: www.ejemplo.com
Respuesta del servidor proxy indicando un tiempo de espera del servidor upstream:
HTTP/1.1 504 Gateway Timeout
Content-Type: text/html<html>
<head>
<title>504 Gateway Timeout</title>
</head>
<body>
<h1>Gateway Timeout</h1>
<p>El servidor proxy no recibió una respuesta a tiempo del servidor upstream.</p>
</body>
</html>
El código HTTP 504 Gateway Timeout indica que un servidor actuando como una puerta de enlace o proxy no recibió una respuesta a tiempo de un servidor upstream necesario para completar la solicitud. Este código se utiliza para señalar problemas de comunicación o retrasos en la respuesta del servidor upstream, y la respuesta puede incluir un mensaje explicativo sobre el problema de tiempo de espera.
El código de respuesta HTTP 506 Variant Also Negotiates es un código de estado de error que indica que el servidor tiene una configuración errónea en la negociación de contenido. Este código se utiliza cuando una variante de un recurso está configurada para participar en la negociación de contenido misma, lo cual crea un bucle infinito o un conflicto en la negociación de contenido.
Explicación detallada:
Propósito:
- Negociación de contenido mal configurada: Informar al cliente de que el servidor tiene un problema de configuración en la negociación de contenido, donde una variante del recurso también está configurada para negociar contenido.
- Evitar bucles infinitos: Prevenir situaciones donde la negociación de contenido podría llevar a bucles infinitos o conflictos.
Uso común:
- Negociación de contenido: Utilizado en sistemas donde la negociación de contenido es utilizada para seleccionar la mejor variante de un recurso basado en las capacidades del cliente o las preferencias de idioma, tipo de contenido, etc.
- Configuraciones avanzadas del servidor: Se aplica en servidores web avanzados que manejan múltiples variantes de recursos y realizan negociaciones de contenido automáticas.
Contenido de la respuesta:
- Mensaje de error: La respuesta puede incluir un mensaje que explique el problema de configuración y sugiera cómo corregirlo.
- Detalles adicionales (opcional): En algunos casos, la respuesta puede proporcionar información adicional sobre la configuración errónea.
Ejemplo de uso:
Solicitud del cliente a un servidor con negociación de contenido:
GET /recurso HTTP/1.1
Host: www.ejemplo.com
Accept: text/html
Respuesta del servidor indicando un problema en la negociación de contenido:
HTTP/1.1 506 Variant Also Negotiates
Content-Type: text/html<html>
<head>
<title>506 Variant Also Negotiates</title>
</head>
<body>
<h1>Variant Also Negotiates</h1>
<p>El servidor encontró un problema de configuración en la negociación de contenido.</p>
</body>
</html>
El código HTTP 506 Variant Also Negotiates indica que el servidor tiene una configuración errónea en la negociación de contenido, donde una variante del recurso también está configurada para negociar contenido, creando un conflicto o un bucle infinito. Este código se utiliza para señalar problemas de configuración avanzados en la negociación de contenido y la respuesta puede incluir un mensaje explicativo sobre el problema.
El código de respuesta HTTP 507 Insufficient Storage indica que el servidor no puede almacenar la representación necesaria para completar la solicitud. Este código se utiliza principalmente en el contexto del protocolo WebDAV (Extensiones para Autoría y Versionado Distribuido Basado en la Web), que es una extensión de HTTP para la manipulación y gestión de archivos en servidores web.
Explicación detallada:
Propósito:
- Almacenamiento insuficiente: Informar al cliente de que el servidor no tiene suficiente espacio de almacenamiento para procesar y almacenar la solicitud completa.
- Manejo de archivos y recursos: Utilizado en operaciones que requieren almacenamiento adicional en el servidor, como la creación, modificación o almacenamiento de archivos grandes.
Uso común:
- Protocolo WebDAV: Utilizado principalmente en el contexto de WebDAV para manejar solicitudes que implican almacenamiento de archivos o recursos grandes.
- Servidores de almacenamiento: En cualquier situación donde el almacenamiento en el servidor es un factor crítico y el servidor no puede completar la solicitud debido a la falta de espacio.
Contenido de la respuesta:
- Mensaje de error: La respuesta puede incluir un mensaje que explique que no hay suficiente espacio de almacenamiento en el servidor para completar la solicitud.
- Detalles adicionales (opcional): En algunos casos, la respuesta puede proporcionar información adicional sobre el espacio de almacenamiento disponible y sugerencias para resolver el problema.
Ejemplo de uso:
Solicitud del cliente para almacenar un archivo grande:
PUT /mi-archivo-grande HTTP/1.1
Host: www.ejemplo.com
Content-Type: application/octet-stream
Content-Length: 104857600[data del archivo]
Respuesta del servidor indicando almacenamiento insuficiente:
HTTP/1.1 507 Insufficient Storage
Content-Type: text/html<html>
<head>
<title>507 Insufficient Storage</title>
</head>
<body>
<h1>Almacenamiento Insuficiente</h1>
<p>El servidor no tiene suficiente espacio de almacenamiento para completar la solicitud.</p>
</body>
</html>
El código HTTP 507 Insufficient Storage indica que el servidor no puede completar la solicitud debido a la falta de espacio de almacenamiento. Este código se utiliza principalmente en el contexto de WebDAV para manejar solicitudes que requieren almacenamiento adicional en el servidor. La respuesta puede incluir un mensaje explicativo y, opcionalmente, información adicional sobre el espacio de almacenamiento disponible y cómo resolver el problema.
El código de respuesta HTTP 508 Loop Detected indica que el servidor ha detectado un bucle infinito mientras procesaba una solicitud con el protocolo WebDAV (Extensiones para Autoría y Versionado Distribuido Basado en la Web). Este código se utiliza cuando una operación se encuentra atrapada en un bucle, lo que impide su finalización.
Explicación detallada:
Propósito:
- Detección de bucles: Informar al cliente de que el servidor ha detectado un bucle infinito durante el procesamiento de la solicitud, lo que impide su finalización.
- Prevención de operaciones sin fin: Evitar que operaciones de servidor entren en bucles interminables, protegiendo los recursos del servidor y evitando la sobrecarga.
Uso común:
- Protocolo WebDAV: Utilizado principalmente en el contexto de WebDAV, donde las operaciones pueden involucrar múltiples recursos y referencias entre ellos, lo que puede causar bucles.
- Operaciones complejas: En sistemas donde las solicitudes pueden generar múltiples referencias a otros recursos, creando la posibilidad de bucles.
Contenido de la respuesta:
- Mensaje de error: La respuesta puede incluir un mensaje que explique que se ha detectado un bucle durante el procesamiento de la solicitud.
- Detalles adicionales (opcional): En algunos casos, la respuesta puede proporcionar información adicional sobre el bucle detectado y cómo corregirlo.
Ejemplo de uso:
Solicitud del cliente que provoca un bucle:
PROPFIND /mi-recurso HTTP/1.1
Host: www.ejemplo.com
Depth: infinity
Respuesta del servidor indicando que se ha detectado un bucle:
HTTP/1.1 508 Loop Detected
Content-Type: text/html<html>
<head>
<title>508 Loop Detected</title>
</head>
<body>
<h1>Bucle Detectado</h1>
<p>El servidor ha detectado un bucle infinito durante el procesamiento de la solicitud.</p>
</body>
</html>
El código HTTP 508 Loop Detected indica que el servidor ha detectado un bucle infinito mientras procesaba una solicitud. Este código se utiliza principalmente en el contexto de WebDAV para manejar situaciones donde las operaciones generan bucles interminables. La respuesta puede incluir un mensaje explicativo y, opcionalmente, información adicional sobre el bucle detectado y cómo corregir el problema.
El código de respuesta HTTP 509 Bandwidth Limit Exceeded es un código de estado no estándar utilizado por algunos servidores web, principalmente cPanel, para indicar que el ancho de banda asignado al servidor o al sitio web ha sido excedido. Este código no está definido en los estándares oficiales de HTTP, pero es utilizado por ciertos sistemas de administración de servidores para gestionar los recursos.
Explicación detallada:
Propósito:
- Límite de ancho de banda: Informar al cliente de que el servidor o sitio web ha excedido el límite de ancho de banda asignado y no puede procesar la solicitud hasta que se restablezcan los límites.
- Gestión de recursos: Ayudar a los administradores del servidor a controlar y limitar el uso de ancho de banda para evitar sobrecargas y garantizar un rendimiento equitativo para todos los usuarios.
Uso común:
- Servidores administrados por cPanel: Comúnmente utilizado en entornos donde se utilizan paneles de control como cPanel para la administración del servidor.
- Hosting compartido: En servicios de hosting compartido donde los recursos como el ancho de banda son limitados y compartidos entre múltiples usuarios y sitios web.
Contenido de la respuesta:
- Mensaje de error: La respuesta generalmente incluye un mensaje que explica que el límite de ancho de banda ha sido excedido y puede proporcionar información sobre cuándo se restablecerán los límites.
- Detalles adicionales (opcional): En algunos casos, la respuesta puede incluir detalles adicionales sobre el límite de ancho de banda y sugerencias para evitar excederlo en el futuro.
Ejemplo de uso:
Solicitud del cliente a un sitio web que ha excedido su límite de ancho de banda:
GET /recurso HTTP/1.1
Host: www.ejemplo.com
Respuesta del servidor indicando que el límite de ancho de banda ha sido excedido:
HTTP/1.1 509 Bandwidth Limit Exceeded
Content-Type: text/html<html>
<head>
<title>509 Bandwidth Limit Exceeded</title>
</head>
<body>
<h1>Límite de Ancho de Banda Excedido</h1>
<p>El servidor ha excedido el límite de ancho de banda asignado. Por favor, intente nuevamente más tarde.</p>
</body>
</html>
El código HTTP 509 Bandwidth Limit Exceeded es un código de estado no estándar utilizado por algunos servidores web para indicar que el ancho de banda asignado ha sido excedido. Este código es útil para gestionar los recursos del servidor y garantizar un uso equitativo del ancho de banda. La respuesta generalmente incluye un mensaje explicativo sobre el problema y puede proporcionar detalles adicionales sobre cuándo se restablecerán los límites.
El código de respuesta HTTP 510 Not Extended indica que la solicitud debe ser extendida más para que el servidor la pueda cumplir. Esto significa que la solicitud actual necesita información adicional o extensiones para que el servidor la procese correctamente.
Explicación detallada:
Propósito:
- Extensiones necesarias: Informar al cliente de que se requieren más detalles o extensiones en la solicitud para que el servidor pueda cumplir con ella.
- Indicación de requerimientos: Indicar que el servidor espera ciertos encabezados o parámetros adicionales que no fueron proporcionados en la solicitud inicial.
Uso común:
- Extensiones HTTP: Utilizado en sistemas que requieren extensiones específicas del protocolo HTTP para procesar la solicitud. Esto puede incluir encabezados adicionales, parámetros de solicitud o características especiales que no están presentes en la solicitud original.
- Negociación de capacidades: Puede ser utilizado cuando el servidor y el cliente están negociando capacidades o características específicas que el servidor necesita para procesar la solicitud.
Contenido de la respuesta:
- Mensaje de error: La respuesta puede incluir un mensaje que explique qué extensiones o información adicional se requiere para que la solicitud sea procesada.
- Detalles adicionales (opcional): En algunos casos, la respuesta puede proporcionar detalles sobre las extensiones específicas que se necesitan y cómo el cliente puede proporcionar esta información.
Ejemplo de uso:
Solicitud del cliente que necesita ser extendida:
GET /api/recurso HTTP/1.1
Host: www.ejemplo.com
Respuesta del servidor indicando que se necesitan extensiones adicionales:
HTTP/1.1 510 Not Extended
Content-Type: text/html<html>
<head>
<title>510 Not Extended</title>
</head>
<body>
<h1>Solicitud No Extendida</h1>
<p>Se requiere información adicional o extensiones en la solicitud para procesarla correctamente. Por favor, proporcione los encabezados o parámetros necesarios.</p>
</body>
</html>
El código HTTP 510 Not Extended indica que la solicitud actual necesita ser extendida con información adicional o extensiones específicas para que el servidor pueda procesarla. Este código se utiliza cuando el servidor requiere más detalles o capacidades específicas no presentes en la solicitud original. La respuesta puede incluir un mensaje explicativo sobre lo que se necesita y cómo el cliente puede proporcionar esta información adicional.
El código de respuesta HTTP 511 Network Authentication Required indica que el cliente necesita autenticarse para obtener acceso a la red. Este código se utiliza cuando el cliente intenta acceder a la red y necesita pasar por un portal cautivo o un sistema de autenticación antes de que se le permita continuar con su solicitud.
Explicación detallada:
Propósito:
- Autenticación de red: Informar al cliente de que necesita autenticarse para acceder a la red. Esto es común en redes Wi-Fi públicas, hoteles, aeropuertos, y otros lugares donde el acceso a Internet está restringido hasta que el usuario se autentique.
- Portal cautivo: Indicar que el usuario debe pasar por un portal cautivo donde se le solicitará autenticación antes de permitir el acceso a Internet.
Uso común:
- Redes públicas y comerciales: Utilizado en entornos donde el acceso a la red requiere autenticación, como en cafeterías, aeropuertos, hoteles, y otros lugares públicos.
- Control de acceso: Implementado para asegurar que solo usuarios autenticados puedan acceder a los recursos de la red.
Contenido de la respuesta:
- Mensaje de error: La respuesta generalmente incluye un mensaje que explique que se requiere autenticación para acceder a la red.
- Detalles adicionales: Puede incluir información sobre cómo autenticarse, como una URL del portal cautivo o instrucciones para completar el proceso de autenticación.
Ejemplo de uso:
Solicitud del cliente que requiere autenticación de red:
GET / HTTP/1.1
Host: www.ejemplo.com
Respuesta del servidor indicando que se requiere autenticación de red:
HTTP/1.1 511 Network Authentication Required
Content-Type: text/html<html>
<head>
<title>511 Network Authentication Required</title>
</head>
<body>
<h1>Autenticación de Red Requerida</h1>
<p>Para acceder a la red, debe autenticarse. Por favor, visite <a href=”http://portal-cautivo.ejemplo.com”>el portal cautivo</a> para autenticarse.</p>
</body>
</html>
El código HTTP 511 Network Authentication Required indica que el cliente debe autenticarse para obtener acceso a la red. Este código es comúnmente utilizado en redes públicas y comerciales donde el acceso a Internet está restringido hasta que el usuario pase por un portal cautivo o un sistema de autenticación. La respuesta puede incluir un mensaje explicativo y detalles sobre cómo completar el proceso de autenticación.
El código de respuesta HTTP 521 Web Server Is Down es un código no estándar utilizado por los servicios de proxy reverso, como Cloudflare, para indicar que no se pudo establecer una conexión con el servidor web origen. Esto significa que el servidor proxy no pudo conectarse al servidor web backend para cumplir con la solicitud del cliente.
Explicación detallada:
Propósito:
- Conexión fallida con el servidor origen: Informar al cliente de que el servidor proxy no pudo conectarse al servidor web origen, posiblemente porque está caído o inaccesible.
- Problemas del servidor backend: Indicar que el problema reside en el servidor web al que se intentó acceder, no en el servidor proxy.
Uso común:
- Servicios de proxy reverso: Utilizado por servicios como Cloudflare cuando actúan como intermediarios entre el cliente y el servidor web origen.
- Redes distribuidas: Común en arquitecturas donde se utiliza un proxy o balanceador de carga para manejar el tráfico hacia múltiples servidores backend.
Contenido de la respuesta:
- Mensaje de error: La respuesta generalmente incluye un mensaje que explique que el servidor web origen está caído o inaccesible.
- Detalles adicionales (opcional): Puede incluir información adicional sobre el problema o sugerencias para resolverlo.
Ejemplo de uso:
Solicitud del cliente a través de un proxy reverso:
GET /api/recurso HTTP/1.1
Host: www.ejemplo.com
Respuesta del proxy indicando que el servidor web origen está caído:
HTTP/1.1 521 Web Server Is Down
Content-Type: text/html<html>
<head>
<title>521 Web Server Is Down</title>
</head>
<body>
<h1>Servidor Web Caído</h1>
<p>El servidor proxy no pudo establecer una conexión con el servidor web origen. El servidor puede estar caído o inaccesible.</p>
</body>
</html>
El código HTTP 521 Web Server Is Down es un código no estándar utilizado por servicios de proxy reverso como Cloudflare para indicar que no se pudo establecer una conexión con el servidor web origen. Esto sugiere que el servidor backend está caído o inaccesible. La respuesta generalmente incluye un mensaje explicativo y puede proporcionar detalles adicionales sobre el problema.
El código de respuesta HTTP 522 Connection Timed Out es un código no estándar utilizado por servicios de proxy reverso como Cloudflare para indicar que no se pudo establecer una conexión TCP con el servidor web origen dentro del tiempo de espera permitido. Esto significa que el servidor proxy no recibió una respuesta o no pudo completar la conexión con el servidor web backend a tiempo.
Explicación detallada:
Propósito:
- Tiempo de espera de conexión: Informar al cliente de que el servidor proxy intentó conectarse al servidor web origen, pero la conexión no se pudo establecer dentro del tiempo permitido.
- Problemas de red o servidor: Indicar que el problema puede deberse a problemas de red, el servidor backend está sobrecargado, o está experimentando tiempos de respuesta lentos.
Uso común:
- Servicios de proxy reverso: Utilizado por servicios como Cloudflare cuando actúan como intermediarios entre el cliente y el servidor web origen.
- Redes distribuidas: Común en arquitecturas donde se utiliza un proxy o balanceador de carga para manejar el tráfico hacia múltiples servidores backend.
Contenido de la respuesta:
- Mensaje de error: La respuesta generalmente incluye un mensaje que explique que la conexión con el servidor web origen se agotó.
- Detalles adicionales (opcional): Puede incluir información adicional sobre el problema o sugerencias para resolverlo.
Ejemplo de uso:
Solicitud del cliente a través de un proxy reverso:
GET /api/recurso HTTP/1.1
Host: www.ejemplo.com
Respuesta del proxy indicando que la conexión se agotó:
HTTP/1.1 522 Connection Timed Out
Content-Type: text/html<html>
<head>
<title>522 Connection Timed Out</title>
</head>
<body>
<h1>Conexión Agotada</h1>
<p>El servidor proxy no pudo establecer una conexión con el servidor web origen dentro del tiempo de espera permitido.</p>
</body>
</html>
El código HTTP 522 Connection Timed Out es un código no estándar utilizado por servicios de proxy reverso como Cloudflare para indicar que no se pudo establecer una conexión TCP con el servidor web origen dentro del tiempo permitido. Esto sugiere problemas de red, sobrecarga del servidor backend, o tiempos de respuesta lentos. La respuesta generalmente incluye un mensaje explicativo y puede proporcionar detalles adicionales sobre el problema.
El código de respuesta HTTP 523 Origin Is Unreachable es un código no estándar utilizado por servicios de proxy reverso como Cloudflare para indicar que el servidor proxy no puede alcanzar el servidor web origen. Esto significa que el servidor proxy no pudo establecer una conexión con el servidor backend debido a que está inactivo, no accesible o está rechazando las conexiones.
Explicación detallada:
Propósito:
- Servidor inaccesible: Informar al cliente de que el servidor proxy no puede acceder al servidor web origen porque está inactivo, no accesible o está rechazando las conexiones.
- Problemas de red o servidor: Indicar que el problema puede deberse a una interrupción en el servidor origen, problemas de red, o configuraciones que bloquean el acceso.
Uso común:
- Servicios de proxy reverso: Utilizado por servicios como Cloudflare cuando actúan como intermediarios entre el cliente y el servidor web origen.
- Redes distribuidas: Común en arquitecturas donde se utiliza un proxy o balanceador de carga para manejar el tráfico hacia múltiples servidores backend.
Contenido de la respuesta:
- Mensaje de error: La respuesta generalmente incluye un mensaje que explique que el servidor web origen no es accesible.
- Detalles adicionales (opcional): Puede incluir información adicional sobre el problema o sugerencias para resolverlo.
Ejemplo de uso:
Solicitud del cliente a través de un proxy reverso:
GET /api/recurso HTTP/1.1
Host: www.ejemplo.com
Respuesta del proxy indicando que el servidor origen es inaccesible:
HTTP/1.1 523 Origin Is Unreachable
Content-Type: text/html<html>
<head>
<title>523 Origin Is Unreachable</title>
</head>
<body>
<h1>Servidor Origen Inaccesible</h1>
<p>El servidor proxy no pudo establecer una conexión con el servidor web origen. El servidor puede estar inactivo, no accesible o rechazando conexiones.</p>
</body>
</html>
El código HTTP 523 Origin Is Unreachable es un código no estándar utilizado por servicios de proxy reverso como Cloudflare para indicar que el servidor proxy no puede alcanzar el servidor web origen. Esto sugiere problemas de inactividad, accesibilidad, o configuraciones que bloquean el acceso al servidor backend. La respuesta generalmente incluye un mensaje explicativo y puede proporcionar detalles adicionales sobre el problema.
El código de respuesta HTTP 525 SSL Handshake Failed es un código no estándar utilizado por servicios de proxy reverso como Cloudflare para indicar que el servidor proxy no pudo completar el handshake SSL/TLS con el servidor web origen. Esto significa que hubo un problema al establecer una conexión segura entre el proxy y el servidor backend.
Explicación detallada:
Propósito:
- Fallo en el handshake SSL/TLS: Informar al cliente de que el servidor proxy no pudo completar el handshake SSL/TLS con el servidor web origen.
- Problemas de configuración de seguridad: Indicar que puede haber problemas de configuración de los certificados SSL/TLS, problemas de compatibilidad entre versiones de TLS, o problemas de red que impiden el handshake.
Uso común:
- Servicios de proxy reverso: Utilizado por servicios como Cloudflare cuando actúan como intermediarios entre el cliente y el servidor web origen y no pueden establecer una conexión segura.
- Redes seguras: Común en arquitecturas que requieren conexiones seguras mediante SSL/TLS para proteger la integridad y confidencialidad de los datos.
Contenido de la respuesta:
- Mensaje de error: La respuesta generalmente incluye un mensaje que explique que el handshake SSL/TLS falló.
- Detalles adicionales (opcional): Puede incluir información adicional sobre el problema, como detalles del error SSL/TLS, para ayudar a diagnosticar y resolver el problema.
Ejemplo de uso:
Solicitud del cliente a través de un proxy reverso:
GET /api/recurso HTTP/1.1
Host: www.ejemplo.com
Respuesta del proxy indicando que el handshake SSL/TLS falló:
HTTP/1.1 525 SSL Handshake Failed
Content-Type: text/html<html>
<head>
<title>525 SSL Handshake Failed</title>
</head>
<body>
<h1>Fallo en el Handshake SSL/TLS</h1>
<p>El servidor proxy no pudo completar el handshake SSL/TLS con el servidor web origen.</p>
</body>
</html>
El código HTTP 525 SSL Handshake Failed es un código no estándar utilizado por servicios de proxy reverso como Cloudflare para indicar que el servidor proxy no pudo completar el handshake SSL/TLS con el servidor web origen. Esto sugiere problemas de configuración de los certificados SSL/TLS, problemas de compatibilidad entre versiones de TLS, o problemas de red que impiden el handshake. La respuesta generalmente incluye un mensaje explicativo y puede proporcionar detalles adicionales sobre el problema para ayudar a resolverlo.
El código de respuesta HTTP 530 Site is Frozen es un código de estado no estándar utilizado por algunos proveedores de hosting, especialmente aquellos que utilizan cPanel, para indicar que el sitio web ha sido “congelado”. Este estado generalmente significa que el acceso al sitio web ha sido suspendido debido a razones administrativas, como el impago, violaciones de términos de servicio, o problemas de abuso.
Explicación detallada:
Propósito:
- Suspensión administrativa: Informar al cliente de que el acceso al sitio web ha sido suspendido por el proveedor de hosting por razones administrativas.
- Problemas de cumplimiento: Indicar que el sitio web puede haber violado los términos de servicio, no ha pagado por el servicio, o está bajo revisión por problemas de abuso.
Uso común:
- Proveedores de hosting: Utilizado por proveedores de hosting, especialmente aquellos que utilizan cPanel para la administración de servidores, para manejar sitios web que han sido suspendidos.
- Sitios web congelados: En situaciones donde el proveedor de hosting necesita suspender temporalmente el acceso a un sitio web por razones específicas.
Contenido de la respuesta:
- Mensaje de error: La respuesta generalmente incluye un mensaje que explique que el sitio web ha sido congelado y puede proporcionar detalles sobre cómo resolver el problema.
- Detalles adicionales: Puede incluir información de contacto del soporte del proveedor de hosting o instrucciones sobre cómo reactivar el sitio.
Ejemplo de uso:
Solicitud del cliente a un sitio web congelado:
GET / HTTP/1.1
Host: www.ejemplo.com
Respuesta del servidor indicando que el sitio está congelado:
HTTP/1.1 530 Site is Frozen
Content-Type: text/html<html>
<head>
<title>530 Site is Frozen</title>
</head>
<body>
<h1>Sitio Congelado</h1>
<p>El acceso a este sitio web ha sido suspendido. Por favor, contacte al soporte de su proveedor de hosting para más información.</p>
</body>
</html>
El código HTTP 530 Site is Frozen es un código de estado no estándar utilizado por algunos proveedores de hosting para indicar que el acceso a un sitio web ha sido suspendido por razones administrativas. Esto puede deberse a problemas como el impago, violaciones de términos de servicio, o abuso. La respuesta generalmente incluye un mensaje explicativo y puede proporcionar detalles adicionales sobre cómo resolver el problema y reactivar el sitio.
El código de respuesta HTTP 599 Network Connect Timeout Error es un código no estándar utilizado por algunos servidores y servicios proxy para indicar que hubo un tiempo de espera al intentar establecer una conexión de red. Este código no forma parte de la especificación oficial de HTTP, pero se utiliza en algunas implementaciones para señalar problemas de conectividad de red.
Explicación detallada:
Propósito:
- Tiempo de espera de conexión de red: Informar al cliente de que el servidor o proxy experimentó un tiempo de espera al intentar establecer una conexión de red.
- Problemas de red: Indicar que el problema puede deberse a una interrupción en la red, un servidor no respondiente, o un tiempo de espera excesivo en la conexión.
Uso común:
- Servidores y proxies personalizados: Utilizado por algunos servidores y servicios proxy personalizados para manejar y registrar errores de tiempo de espera en la conexión de red.
- Diagnóstico de red: Ayudar a los administradores y desarrolladores a diagnosticar problemas de conectividad de red.
Contenido de la respuesta:
- Mensaje de error: La respuesta generalmente incluye un mensaje que explique que hubo un tiempo de espera al intentar establecer una conexión de red.
- Detalles adicionales (opcional): Puede incluir información adicional sobre el problema de la red, aunque esto depende de la implementación específica.
Ejemplo de uso:
Solicitud del cliente que experimenta un tiempo de espera de red:
GET /api/recurso HTTP/1.1
Host: www.ejemplo.com
Respuesta del servidor indicando un tiempo de espera en la conexión de red:
HTTP/1.1 599 Network Connect Timeout Error
Content-Type: text/html<html>
<head>
<title>599 Network Connect Timeout Error</title>
</head>
<body>
<h1>Error de Tiempo de Espera en la Conexión de Red</h1>
<p>El servidor experimentó un tiempo de espera al intentar establecer una conexión de red.</p>
</body>
</html>
El código HTTP 599 Network Connect Timeout Error es un código de estado no estándar utilizado por algunos servidores y servicios proxy para indicar que hubo un tiempo de espera al intentar establecer una conexión de red. Este código sugiere problemas de conectividad de red y se utiliza para ayudar a diagnosticar problemas de red. La respuesta generalmente incluye un mensaje explicativo y puede proporcionar detalles adicionales sobre el problema de la red.