031.3 Lección 1

La primera etapa de un intercambio de datos HTTP entre el cliente y el servidor es iniciada por el primero, cuando escribe un mensaje de solicitud en el servidor. Tomemos, por ejemplo, una tarea común del navegador: cargar una página HTML desde un servidor que aloja un sitio web, como https://learning.lpi.org/en/. La dirección, o URL, proporciona varios datos relevantes. En este ejemplo en particular, aparecen tres datos:

Una vez que el servidor HTTP recibe el encabezado del mensaje de solicitud, el servidor devuelve un mensaje de respuesta al cliente. Una solicitud de archivo HTML normalmente tiene un encabezado de respuesta como este:

La primera línea proporciona la versión del protocolo HTTP utilizada en el mensaje de respuesta, que debe corresponder a la versión utilizada en el encabezado de la solicitud. Luego, todavía en la primera línea, aparece el código de estado de la respuesta, indicando cómo el servidor interpretó y generó la respuesta a la solicitud.

El código de estado es un número de tres dígitos, donde el dígito más a la izquierda define la clase de respuesta. Hay cinco clases de códigos de estado, numerados del 1 al 5, cada uno de los cuales indica un tipo de acción realizada por el servidor:

El segundo y tercer dígitos se utilizan para indicar detalles adicionales. El código 200, por ejemplo, indica que la solicitud podría ser respondida sin problemas. Como se muestra en el ejemplo, también se puede proporcionar una breve descripción de texto después del código de respuesta (OK). Algunos códigos específicos son de particular interés para garantizar que el cliente HTTP pueda acceder al recurso en situaciones adversas o para ayudar a identificar el motivo del error en caso de que una solicitud no sea satisfactoria:

Aunque indican que no fue posible cumplir con la solicitud, los códigos de estado 4xx y 5xx al menos indican que el servidor HTTP se está ejecutando y es capaz de recibir solicitudes. Los códigos 4xx requieren que se realice una acción en el cliente, porque su URL o credenciales son incorrectas. Por el contrario, los códigos 5xx indican algo incorrecto en el lado del servidor. Por lo tanto, en el contexto de las aplicaciones web, estas dos clases de códigos de estado indican que el origen del error se encuentra en la propia aplicación, ya sea cliente o servidor, no en la infraestructura subyacente.

Los servidores HTTP utilizan dos mecanismos básicos para cumplir con el contenido solicitado por el cliente. El primer mecanismo proporciona contenido estático: es decir, la ruta indicada en el mensaje de solicitud corresponde a un archivo en el sistema de archivos local del servidor. El segundo mecanismo proporciona contenido dinámico: es decir, el servidor HTTP reenvía la solicitud a otro programa, probablemente un script, para generar la respuesta a partir de diferentes fuentes, como bases de datos y otros archivos.

Aunque existen diferentes servidores HTTP, todos utilizan el mismo protocolo de comunicación HTTP y adoptan más o menos las mismas convenciones. Una aplicación que no tiene una necesidad específica se puede implementar con cualquier servidor tradicional, como Apache o NGINX. Ambos son capaces de generar contenido dinámico y proporcionar contenido estático, pero existen sutiles diferencias en la configuración de cada uno.

La ubicación de los archivos estáticos que se entregarán, por ejemplo, se define de diferentes formas en Apache y NGINX. La convención es mantener estos archivos en un directorio específico para este propósito, con un nombre asociado con el host, por ejemplo, /var/www/learning.lpi.org/. En Apache, esta ruta está definida por la directiva de configuración DocumentRoot /var/www/learning.lpi.org, en una sección que define un host virtual. En NGINX, la directiva utilizada es root /var/www/learning.lpi.org en la sección de server del archivo de configuración.

Cualquiera que sea el servidor que elija, los archivos en /var/www/learning.lpi.org/ se servirán a través de HTTP casi de la misma manera. Algunos campos en el encabezado de respuesta y su contenido pueden variar entre los dos servidores, pero campos como Content-Type deben estar presentes en el encabezado de respuesta y deben ser consistentes en cualquier servidor.

HTTP fue diseñado para funcionar en cualquier tipo de conexión a Internet, rápida o lenta. Además, la mayoría de los intercambios HTTP tienen que atravesar muchos nodos de red debido a la arquitectura distribuida de Internet. Como resultado, es importante adoptar alguna estrategia de almacenamiento en caché para evitar la transferencia redundante de contenido descargado previamente. Las transferencias HTTP pueden funcionar con dos tipos básicos de caché: shared y private.

Más de un cliente utiliza una caché compartida. Por ejemplo, un gran proveedor de contenido puede utilizar cachés en servidores distribuidos geográficamente, de modo que los clientes obtengan los datos de su servidor más cercano. Una vez que un cliente ha realizado una solicitud y su respuesta se almacenó en una caché compartida, otros clientes que realicen la misma solicitud en esa misma área recibirán la respuesta en caché.

El propio cliente crea una caché privada para su uso exclusivo. Es el tipo de almacenamiento en caché que hace el navegador web para imágenes, archivos CSS, JavaScript o el documento HTML en sí, por lo que no es necesario volver a descargarlos si se solicita en un futuro próximo.

Tanto la estrategia de caché compartida como la privada utilizan encabezados HTTP para controlar cómo se debe almacenar el contenido descargado. Para la caché privada, el cliente consulta el encabezado de respuesta y verifica si el contenido de la caché local todavía corresponde al contenido remoto actual. Si lo hace, el cliente renuncia a la transferencia del payload de respuesta y usa la versión local.

La validez del recurso almacenado en caché se puede evaluar de varias formas. El servidor puede proporcionar una fecha de vencimiento en el encabezado de respuesta para la primera solicitud, de modo que el cliente descarta el recurso almacenado en caché al final del plazo y lo solicita nuevamente para obtener la versión actualizada. Sin embargo, el servidor no siempre puede determinar la fecha de vencimiento de un recurso, por lo que es común usar el campo de encabezado de respuesta ETag para identificar la versión del recurso, por ejemplo, Etag: "606adcd4-46fa".

Para verificar que un recurso almacenado en caché necesita actualizarse, el cliente solicita solo su encabezado de respuesta del servidor. Si el campo ETag coincide con el de la versión almacenada localmente, el cliente reutiliza el contenido almacenado en caché. De lo contrario, el contenido actualizado del recurso se descarga del servidor.

En un sitio web o aplicación web convencional, las funciones que manejan el control de sesión se basan en encabezados HTTP. El servidor no puede asumir, por ejemplo, que todas las solicitudes que provienen de la misma dirección IP son del mismo cliente. El método más tradicional que permite al servidor asociar diferentes solicitudes a un solo cliente es el uso de cookies, una etiqueta de identificación que le da el servidor al cliente y que se proporciona en el encabezado HTTP.

Las cookies permiten al servidor conservar información sobre un cliente específico, incluso si la persona que ejecuta el cliente no se identifica explícitamente. Con las cookies, es posible implementar sesiones donde los inicios de sesión, tarjetas de compra, preferencias, etc., se conservan entre diferentes solicitudes realizadas al mismo servidor que las proporcionó. Las cookies también se utilizan para rastrear la navegación del usuario, por lo que es importante solicitar su consentimiento antes de enviarlas.

El servidor establece la cookie en el encabezado de respuesta utilizando el campo Set-Cookie. El valor del campo es un par name=value elegido para representar algún atributo asociado con un cliente específico. El servidor puede, por ejemplo, crear un número de identificación para un cliente que solicita un recurso por primera vez y pasarlo al cliente en el encabezado de respuesta:

Si el cliente permite el uso de cookies, las nuevas solicitudes a este mismo servidor tienen el campo de cookies en el encabezado:

Con este número de identificación, el servidor puede recuperar definiciones específicas para el cliente y generar una respuesta personalizada. También es posible utilizar más de un campo Set-Cookie para entregar diferentes cookies al mismo cliente. De esta forma, se puede conservar más de una definición en el lado del cliente.

Las cookies plantean tanto problemas de privacidad como posibles agujeros de seguridad, porque existe la posibilidad de que se puedan transferir a otro cliente, que será identificado por el servidor como el cliente original. Las cookies utilizadas para conservar sesiones pueden dar acceso a información confidencial del cliente original. Por tanto, es muy importante que los clientes adopten mecanismos de protección local para evitar que sus cookies sean extraídas y reutilizadas sin autorización.