VoriTools

Crear y analizar Cache-Control

Selecciona las directivas o pega una cabecera existente. El análisis se aplica al texto, no al funcionamiento real de una caché.

Se ejecuta localmente en tu navegador
Ver categoría: Red y HTTP (19)
Esta herramienta procesa todos los datos localmente en tu navegador.
Política de respuestaElige la política que enviará la respuesta de origen.
Inspeccionar valor Cache-ControlPega solo el valor de directivas o una línea de cabecera completa.

Cómo crear y analizar una cabecera Cache-Control

El panel superior compone una política de respuesta: elige una visibilidad, añade un periodo de vigencia en segundos, marca las directivas que necesites y pulsa Crear cabecera. La cabecera que enviaría la página aparece en el cuadro Cabecera de respuesta con un resumen de tres líneas —cuántas directivas hay, qué vigencia tiene la respuesta y qué cachés pueden conservarla— y, debajo, cada conflicto que contiene la combinación. El panel inferior hace lo contrario: pega un valor copiado de una respuesta, de la configuración de un CDN o de un registro, pulsa Inspeccionar cabecera y lee ese mismo resumen para ese texto. Los dos paneles funcionan en este navegador y la página sigue operativa sin conexión.

Cache-Control es el campo de respuesta HTTP que indica a las cachés cuánto tiempo pueden reutilizar una respuesta y qué deben comprobar antes: max-age y s-maxage fijan la duración para navegadores y cachés compartidas, no-store prohíbe almacenar, no-cache permite almacenar pero exige validar, e immutable, stale-while-revalidate y stale-if-error matizan todo eso. Esta herramienta lee el texto de la cabecera según la RFC 9111 e indica qué haría una caché con él. Nunca contacta con una URL, así que no puede decir qué hacen realmente tu servidor, tu CDN o la caché de un navegador en producción.

  1. Elige el destinatario en Visibilidad: public si la respuesta pueden almacenarla cachés compartidas, private si la copia es para un solo usuario, o sin visibilidad explícita si el campo no debe pronunciarse. La opción se escribe en la cabecera tal como se lee.
  2. Rellena max-age para los navegadores y s-maxage cuando un CDN o un proxy inverso necesite su propia duración. Las ventanas opcionales —stale-while-revalidate y stale-if-error— y las cinco marcas solo se añaden si las usas. Los segundos son dígitos enteros: 3600 y no 3600.9, que la página avisa en lugar de redondear a escondidas.
  3. Pulsa Crear cabecera y lee el cuadro Cabecera de respuesta: contiene la línea del campo tal como se enviaría, en el orden en que el formulario enumera las directivas. El resumen inferior las cuenta, indica la vigencia y el ámbito, y enumera cada conflicto encontrado: public con private, no-store con una duración, immutable sin max-age, s-maxage con private.
  4. Para revisar una cabecera que ya existe, pégala en el segundo panel: la lista de directivas sola o la línea Cache-Control completa. La forma entre comillas se lee bien, así que no-cache="Set-Cookie, Authorization" sigue siendo una sola directiva. Los nombres desconocidos, los duplicados, los delta-seconds entre comillas y los valores que no son dígitos se avisan en lugar de darse por buenos.
  5. Copiar lleva la línea al portapapeles y Descargar la guarda como cache-control.txt. Limpiar devuelve el formulario a sus valores por defecto —public con max-age=3600— y vacía los dos paneles, así que la siguiente ejecución empieza en un estado conocido. Cuando un valor no se puede leer, la línea de estado indica el campo y el motivo, y el cuadro de la cabecera se vacía en vez de quedarse con el resultado anterior.

Conflictos, delta-seconds y lo que esta herramienta no puede ver

Los conflictos que avisa esta herramienta

public y private se contradicen: public marca la respuesta como almacenable por cachés compartidas y private se lo prohíbe justamente a esas cachés, así que sobra una de las dos. no-store es la directiva más fuerte —no se puede almacenar nada—, de modo que max-age, s-maxage y las ventanas de contenido obsoleto no sirven de nada en la misma cabecera; el resumen lo dice en lugar de mostrar una vigencia que nunca se aplicará. s-maxage solo lo leen las cachés compartidas y private las excluye, así que s-maxage junto a private no tiene efecto.

immutable promete que el recurso no cambiará mientras esté vigente (RFC 8246); sin max-age ni s-maxage no hay ninguna ventana de vigencia que esa promesa cubra. must-understand va junto a no-store, y una caché que entiende los requisitos de caché de ese código de estado ignora la parte no-store (RFC 9111, sección 5.2.2.3). También se avisa si no hay duración: sin max-age, s-maxage ni no-cache, una caché puede recurrir a una heurística —habitualmente una décima parte del tiempo desde Last-Modified— y reutilizar la respuesta sin consultar al origen.

Delta-seconds: los números que acepta una caché

max-age, s-maxage, stale-while-revalidate y stale-if-error llevan delta-seconds, que la RFC 9111 define como uno o más dígitos (sección 1.2.2): 0 es válido y significa obsoleto de inmediato, y el punto decimal no forma parte de la gramática. Un valor entre comillas como max-age="5" se avisa porque quien lo envía debe usar la forma de token (sección 5.2.2.1). También se avisa si se superan 2147483647 segundos: una caché que no pueda representar esa cifra debe leerla como 2147483648 segundos, más de 68 años, lo que equivale a no quedar obsoleta nunca.

La otra forma de argumento en este campo es la lista de nombres de campo entre comillas de no-cache y private, como no-cache="Set-Cookie". Las comas dentro de esas comillas pertenecen a la lista, así que el analizador divide el campo por las comas que quedan fuera de las comillas y cuenta ese valor como una sola directiva. Las directivas que una caché no reconoce las ignora esa caché (sección 5.2.3), y por eso merece la pena avisar de una errata como maz-age=60: la respuesta se serviría igual y la regla simplemente no existiría.

Lo que esta herramienta no puede decirte

La página nunca envía una petición: solo lee el texto de la cabecera. Que un CDN, un proxy inverso o un navegador respete el campo depende de la configuración de ese sistema y del código de estado de la respuesta, y una caché puede almacenar una respuesta sin ninguna directiva si la considera cacheable por heurística. Comprueba la política en la respuesta real —curl -I, las cabeceras de caché que informa tu CDN o el panel de red del navegador— antes de confiar en ella.

Dos vecinos de este campo quedan fuera a propósito: Expires da una fecha absoluta en lugar de una duración, y Pragma es un campo de petición de HTTP/1.0 que la RFC 9111 deja obsoleto (sección 5.4). Por eso se rechaza una línea que empieza con otro nombre de campo en lugar de reetiquetarla como Cache-Control. Y como la comprobación es textual, una cabecera impecable puede seguir siendo equivocada para el contenido que hay detrás: no-store en un recurso estático o un max-age de un año en una página que cambia cada hora son decisiones que ningún analizador puede tomar por ti.

Herramientas recientes: