HTTP en Profundidad

Evolución de Versiones HTTP #

HTTP ha evolucionado significativamente desde su creación, y cada versión introduce cambios que afectan directamente cómo testeas aplicaciones web. Entender estas diferencias es esencial para diagnosticar problemas de rendimiento y escribir aserciones de test precisas.

HTTP/1.1: El Caballo de Batalla #

HTTP/1.1 ha impulsado la web desde 1997. Sus características clave incluyen conexiones persistentes (reutilizar una conexión TCP para múltiples requests) y pipelining (enviar múltiples requests sin esperar respuestas). Sin embargo, HTTP/1.1 sufre de bloqueo head-of-line — si un request es lento, todos los requests subsiguientes en la misma conexión deben esperar.

Implicaciones para testing:

• Los navegadores abren 6-8 conexiones paralelas por dominio para sortear el bloqueo head-of-line
• Domain sharding (servir assets desde múltiples subdominios) era una optimización común — testea que funcione correctamente
• Cada request/response incluye headers completos basados en texto, agregando overhead

HTTP/2: La Revolución del Multiplexing #

HTTP/2, estandarizado en 2015, introdujo varias características revolucionarias:

• Multiplexing: Múltiples requests y responses comparten una sola conexión TCP simultáneamente. No más bloqueo head-of-line a nivel HTTP.
• Compresión de headers (HPACK): Reduce el overhead de headers en 85-90% usando una tabla de compresión.
• Server push: El servidor puede enviar recursos proactivamente antes de que el cliente los solicite.
• Framing binario: HTTP/2 usa formato binario en vez de texto, haciendo el parsing más rápido y menos propenso a errores.

Implicaciones para testing:

• Domain sharding en realidad perjudica el rendimiento de HTTP/2 — testea con un solo dominio
• Server push puede precargar recursos críticos — verifica que funcione y no envíe contenido obsoleto
• HTTP/2 aún corre sobre TCP, por lo que el bloqueo head-of-line a nivel TCP permanece

HTTP/3: QUIC y UDP #

HTTP/3, construido sobre el protocolo QUIC sobre UDP, resuelve el problema restante de bloqueo head-of-line de TCP. Características clave:

• Transporte QUIC: Basado en UDP con cifrado integrado (TLS 1.3 es obligatorio)
• Establecimiento de conexión 0-RTT: Las conexiones repetidas pueden enviar datos inmediatamente sin handshake
• Streams independientes: La pérdida en un stream no bloquea otros (a diferencia de TCP donde un solo paquete perdido bloquea todo)

Implicaciones para testing:

• HTTP/3 usa el puerto UDP 443 — los firewalls pueden bloquearlo, causando fallback a HTTP/2
• 0-RTT tiene riesgos de ataques de replay — testea que tu aplicación lo maneje de forma segura
• No todos los clientes/servidores soportan HTTP/3 aún — testea el comportamiento de fallback

Headers HTTP Avanzados #

Los headers HTTP llevan metadata que controla caching, seguridad, negociación de contenido y comportamiento cross-origin. Los ingenieros QA deben verificar estos headers en cada endpoint.

Headers de Caching #

Qué testear: Verifica que las respuestas API dinámicas incluyan Cache-Control: no-store y los assets estáticos tengan max-age apropiado. Testea que los requests condicionales (If-None-Match, If-Modified-Since) devuelvan 304 correctamente.

Headers CORS #

Qué testear: Verifica que los headers CORS estén presentes en las respuestas API, testea que los requests preflight OPTIONS devuelvan headers correctos, y verifica que el wildcard (*) no se use cuando se requieren credenciales.

Headers de Seguridad #

Técnicas de Depuración HTTP #

Tab Network de DevTools del Navegador #

La pestaña Network es la herramienta de depuración HTTP más poderosa disponible para ingenieros QA:

• Desglose de tiempos: DNS lookup, conexión TCP, handshake TLS, TTFB, descarga de contenido
• Headers de request/response: Inspección completa de headers para cada request
• Filtrado: Por tipo (XHR, JS, CSS), status code, o búsqueda de texto
• Throttling: Simular condiciones de red lentas
• Preserve log: Mantener historial de red entre navegaciones

curl para Depuración HTTP #

# Salida verbose mostrando todos los headers y timing
curl -v https://api.example.com/users

# Desglose de timing
curl -w "DNS: %{time_namelookup}s\nConnect: %{time_connect}s\nTLS: %{time_appconnect}s\nTTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n" -o /dev/null -s https://api.example.com

# Forzar HTTP/2
curl --http2 -v https://api.example.com

# Testear IP específica sin DNS
curl --resolve api.example.com:443:10.0.0.1 https://api.example.com

Testing HTTP Avanzado #

Testing de HTTP/2 Server Push #

Server push permite al servidor enviar recursos antes de que el cliente los solicite. El testing requiere verificar:

1. Los recursos enviados coinciden con lo que la página realmente necesita
2. Los recursos no están obsoletos (validación de caché)
3. El push no desperdicia ancho de banda en recursos que el cliente ya tiene
4. Las push promises usan headers correctos

# Verificar push promises de HTTP/2 usando nghttp
nghttp -v https://example.com | grep "push promise"

Atributos de Seguridad de Cookies #

Las cookies modernas deben incluir atributos de seguridad que QA debe verificar:

Testing HSTS #

# Verificar header HSTS
curl -sI https://example.com | grep -i strict-transport

# Verificar elegibilidad de HSTS preload
# El header debe incluir: max-age=31536000; includeSubDomains; preload

Connection Coalescing en HTTP/2 #

HTTP/2 permite reutilizar una conexión para múltiples dominios si comparten la misma dirección IP y certificado TLS. Esto puede causar comportamiento inesperado en testing:

• Requests a api.example.com y cdn.example.com pueden compartir una conexión
• Si un dominio tiene diferentes requisitos CORS o auth, compartir causa problemas
• Testea que el coalescing no evite límites de seguridad

Ejercicio Práctico #

Audita la configuración HTTP de un sitio web usando curl y DevTools del navegador:

1. Verifica versión HTTP: ¿Qué versión soporta el servidor? ¿Negocia correctamente?
2. Analiza headers de caching: ¿Los assets estáticos están cacheados? ¿Las respuestas API no están cacheadas?
3. Verifica política CORS: ¿La API devuelve headers CORS correctos? Testea desde un origen diferente.
4. Testea headers de seguridad: ¿HSTS está configurado? ¿CSP está presente?
5. Mide tiempos: ¿Cuál es el desglose de DNS, TLS y TTFB? ¿Dónde están los cuellos de botella?

# 1. Verificar versión HTTP
curl -sI https://example.com | head -1
curl --http2 -sI https://example.com | head -1

# 2. Headers de caching
curl -sI https://example.com/style.css | grep -i cache
curl -sI https://api.example.com/data | grep -i cache

# 3. CORS (testear desde origen diferente)
curl -H "Origin: https://evil.com" -sI https://api.example.com/data | grep -i access-control

# 4. Headers de seguridad
curl -sI https://example.com | grep -iE "strict-transport|content-security|x-frame|x-content-type"

# 5. Timing
curl -w "DNS:%{time_namelookup} TLS:%{time_appconnect} TTFB:%{time_starttransfer} Total:%{time_total}\n" -o /dev/null -s https://example.com

Pro Tips #

• Siempre verifica la versión HTTP en uso — el comportamiento de HTTP/2 difiere significativamente de HTTP/1.1, especialmente en gestión de conexiones y manejo de headers
• Testea CORS desde el navegador, no solo curl — los navegadores aplican CORS mientras curl no, generando falsa confianza al testear solo desde la línea de comandos
• Verifica headers de caching en cada endpoint — el caching incorrecto es una de las causas más comunes de bugs de datos obsoletos en producción
• Usa curl --resolve para testear contra IPs específicas sin cambios DNS — invaluable para testear despliegues antes del corte DNS
• Verifica HSTS preload en aplicaciones críticas de seguridad — sin preload, la primera visita sigue vulnerable a ataques de degradación

Puntos Clave #

1. Las diferencias entre versiones HTTP (1.1, 2, 3) tienen implicaciones significativas para performance testing y configuración de infraestructura de tests
2. Caching, CORS y headers de seguridad son puntos de verificación críticos en cada endpoint HTTP
3. La pestaña Network de DevTools es la herramienta de depuración HTTP más valiosa para ingenieros QA
4. Siempre testea CORS en navegadores reales — las herramientas de API testing no aplican las políticas de seguridad del navegador