Analizador de cabeceras HTTP

Sí. El analizador detecta automáticamente si la entrada es una solicitud o respuesta HTTP basándose en la primera línea y la analiza en consecuencia. Las líneas de solicitud comienzan con un método HTTP (GET, POST, etc.) mientras que las líneas de respuesta comienzan con HTTP/versión.

Sí. Las cabeceras Set-Cookie se analizan en cookies individuales mostrando nombre, valor y todos los indicadores como HttpOnly, Secure, SameSite, Path, Domain y Max-Age.

Formato estándar de cabeceras HTTP/1.1 y HTTP/2 con una cabecera por línea en el formato "Nombre: Valor". Puedes copiar las cabeceras directamente desde las herramientas de desarrollo del navegador.

Las solicitudes suelen llevar host, user-agent, accept, accept-encoding y cookie; las respuestas contestan con content-type, content-length, cache-control, set-cookie y date. El tráfico de API añade authorization y content-type: application/json en la entrada, y cabeceras rate-limit en la salida. La RFC 9110 (semántica de HTTP, 2022) es la referencia moderna que las define todas.

Las cabeceras de solicitud (host, authorization, accept-*) describen lo que el cliente quiere; las cabeceras de respuesta (location, set-cookie, retry-after) describen lo que se devolvió. Algunos campos aparecen en ambas direcciones (cache-control, content-type), y unos pocos gobiernan la propia conexión (connection: keep-alive) en lugar del contenido del mensaje. Este analizador indica a qué lado pertenece cada cabecera.

Según la RFC 9110, la mayoría de los campos repetidos se combinan en una sola lista separada por comas: dos líneas cache-control y una sola línea que diga no-cache, no-store son equivalentes. Set-Cookie es la excepción documentada: nunca se puede fusionar con comas porque las fechas de Expires contienen comas, por lo que los proxies deben reenviar cada Set-Cookie por separado. Esa excepción es una fuente clásica de errores en proxies.

Los nombres de campo pasaron a minúsculas y viajan como tramas binarias comprimidas con HPACK o QPACK; cada solicitud abre su propio stream, y las cabeceras por conexión como Host fueron reemplazadas por la pseudo-cabecera :authority junto con :method, :scheme y :path. Semánticamente los campos siguen la RFC 9110: lo que cambió es el formato en el cable, no el vocabulario.

Espacios en blanco entre el nombre del campo y los dos puntos (Header : value): tanto el análisis de HTTP/1.1 como la especificación de HTTP/2 lo rechazan para evitar el request smuggling. También es inválido: espacios o bytes no ASCII dentro del nombre del campo, caracteres de control en los valores, y obs-fold (una cabecera continuada en una línea con sangría), que la RFC 9110 marca como obsoleto: reemplázalo con una sola línea o con un valor de lista.