Qué revisa esta herramienta
Dada una URL, esta herramienta la solicita dos veces desde los servidores de Pingfloat — una vez normalmente y otra vez rechazando explícitamente la compresión — y reporta las cabeceras de respuesta sin procesar, si la respuesta está comprimida (gzip/brotli), si está cacheada por un CDN, y si están presentes las cabeceras de seguridad comunes.
Por qué importan las cabeceras de seguridad
Las cabeceras de respuesta HTTP como Content-Security-Policy y Strict-Transport-Security son instrucciones para el navegador sobre cómo tratar la página de forma defensiva — no cambian cómo se ve la página, pero cierran categorías enteras de ataques (XSS, clickjacking, degradación de protocolo) a nivel del navegador, sin necesidad de cambiar código en la página misma.
Referencia de cabeceras comunes
| Cabecera | Qué hace |
|---|---|
Authorization | Lleva las credenciales (por ejemplo, Bearer <token>) para autenticar una solicitud. |
Retry-After | Se envía con una respuesta 429 Too Many Requests o 503 Service Unavailable — le indica al cliente cuánto esperar antes de reintentar, ya sea como una cantidad de segundos o una fecha HTTP. |
Idempotency-Key | Un valor único generado por el cliente (común en APIs de pago como Stripe) que le permite a un servidor ignorar de forma segura una solicitud duplicada accidental — por ejemplo, un reintento después de un timeout — sin procesarla dos veces. Todavía no es un RFC central del IETF, pero está ampliamente soportado como estándar de facto. |
Host | El dominio (y el puerto, si no es el predeterminado) que el cliente está solicitando — la única cabecera obligatoria en toda solicitud HTTP/1.1, ya que es lo que permite que una sola IP de servidor aloje varios dominios. |
Accept | Le indica al servidor qué tipos de contenido puede manejar el cliente (por ejemplo, application/json), para que el servidor elija el formato de respuesta correcto. |
Preguntas frecuentes
¿Por qué esta herramienta hace dos solicitudes en vez de una?
Comparar una solicitud normal contra una que rechaza explícitamente la compresión (Accept-Encoding: identity) revela si un servidor está negociando la compresión correctamente, en vez de simplemente comprimir siempre (o nunca) sin importar lo que el cliente pueda manejar.
¿Esta herramienta reporta la relación de compresión o el tamaño ahorrado?
No — la capa fetch del navegador descomprime de forma transparente el cuerpo de la respuesta antes de que JavaScript lo vea siquiera, y muchas respuestas reales usan transferencia por fragmentos (chunked) sin ninguna cabecera Content-Length. Por eso no hay forma confiable de recuperar el tamaño comprimido real después del hecho. Esta herramienta se limita a lo que realmente se puede verificar: qué codificación se negoció, a partir de las cabeceras mismas.
¿Una cabecera de seguridad faltante siempre es un problema?
No necesariamente — depende del sitio. Una API que nunca renderiza HTML no confiable necesita menos una Content-Security-Policy que un sitio que acepta contenido generado por usuarios, por ejemplo. Trata esto como algo que merece una decisión deliberada, no como un requisito universal.
¿Los nombres de las cabeceras HTTP distinguen mayúsculas de minúsculas?
No — según el RFC 9110, los nombres de los campos de cabecera HTTP son explícitamente insensibles a mayúsculas y minúsculas: Content-Type, content-type y CONTENT-TYPE son la misma cabecera. Por eso esta herramienta (y la mayoría de las librerías HTTP, incluyendo curl y la Fetch API) normalizan los nombres de cabecera a minúsculas internamente. Los valores de las cabeceras son otra historia — algunos, como los nombres de cookies o las credenciales de Basic Auth, sí distinguen mayúsculas de minúsculas, así que no asumas que aplica la misma regla ahí.
¿Por qué me aparece un error "431 Request Header Fields Too Large"?
La mayoría de los servidores y proxies inversos limitan el tamaño total de las cabeceras de solicitud (comúnmente entre 8KB y 16KB) para protegerse contra abusos. Esto suele acumularse gradualmente — cookies acumuladas, un JWT grande guardado en una cabecera Authorization, o una larga cadena de cabeceras reenviadas por proxies — hasta que una solicitud finalmente supera el límite y es rechazada con un 431. Pasa las respuestas de una página por esta herramienta para ver exactamente qué cabeceras están presentes y aproximadamente qué tan grandes son, como punto de partida para rastrear cuál creció demasiado.