Vary

Uso

Una misma URL suele producir respuestas distintas según lo que envíe el cliente. Un servidor que comprime con gzip para un cliente y con Brotli para otro sirve dos representaciones distintas del mismo recurso. La cabecera Vary registra qué cabeceras de solicitud llevaron al servidor a elegir una representación concreta, y así proporciona a las cachés la información necesaria para almacenar y hacer coincidir la copia correcta.

Cuando una caché recibe una solicitud de una URL de la que tiene una respuesta almacenada, compara las cabeceras indicadas en Vary entre la nueva solicitud y la almacenada. Si los valores coinciden, la respuesta en caché es válida. Si difieren, la caché obtiene una respuesta nueva del servidor de origen.

Los valores más habituales son Accept-Encoding (para la negociación de compresión) y Accept (para la negociación de contenido). Las configuraciones de servicio dinámico que entregan distinto HTML a clientes móviles y de escritorio según la cadena User-Agent añaden Vary: User-Agent para señalar esa variación.

El valor comodín * significa que cada solicitud se considera única y, en la práctica, desactiva el almacenamiento en caché del recurso. Rara vez es apropiado y la mayoría de las cachés tratan una respuesta Vary: * como no almacenable en caché.

Nota

Google no utiliza la cabecera Vary para entender las relaciones entre móvil y escritorio de cara a la indexación en buscadores. La cabecera es un mecanismo de caché, no una señal de búsqueda. Los sitios que usan servicio dinámico con Vary: User-Agent siguen beneficiándose de un comportamiento de caché correcto, pero la cabecera en sí no influye en cómo Google descubre o indexa el contenido móvil. Google también desaconseja convertir las URL m-dot en la versión canónica, pese a la indexación centrada en móvil, y recomienda el diseño adaptable como configuración preferida.

Accept-Encoding

Indica que la respuesta varía según la cabecera de solicitud Accept-Encoding. Los distintos algoritmos de compresión (gzip, br, zstd) producen cuerpos de respuesta diferentes para el mismo recurso. Es el valor de Vary más utilizado.

Accept

Indica que la respuesta varía según la cabecera de solicitud Accept. La negociación de contenido entrega distintos tipos de medio (HTML, JSON, XML) desde la misma URL en función de la preferencia del cliente.

Accept-Language

Indica que la respuesta varía según la cabecera de solicitud Accept-Language. Los sitios multilingües que sirven contenido localizado desde la misma URL incluyen este valor.

User-Agent

Indica que la respuesta varía según la cabecera de solicitud User-Agent. Las configuraciones de servicio dinámico entregan distinto HTML a clientes móviles y de escritorio desde la misma URL.

Cookie

Vary: Cookie significa que la respuesta difiere según el valor de la cabecera Cookie. Las cachés almacenan una variante independiente para cada cadena Cookie única, lo que provoca una fragmentación de caché considerable, ya que cada usuario autenticado tiene una cookie de sesión distinta. Limite Vary: Cookie a las respuestas que realmente dependen de los valores de las cookies (páginas personalizadas, paneles de control) y evite establecer ese valor en recursos estáticos públicos.

* (wildcard)

El valor comodín señala que la respuesta varía por factores que no quedan recogidos en ninguna cabecera de solicitud. Las cachés lo tratan como no almacenable en caché. Rara vez se usa de forma intencionada.

Ejemplo

Un servidor comprime las respuestas con la codificación solicitada por el cliente. La cabecera Vary: Accept-Encoding indica a las cachés intermedias que almacenen copias separadas para las solicitudes gzip y Brotli, en lugar de servir una respuesta comprimida con gzip a un cliente compatible con Brotli.

Vary: Accept-Encoding

Una configuración de negociación de contenido entrega JSON o HTML desde el mismo punto de acceso. La caché almacena respuestas separadas según el valor de la cabecera Accept.

Vary: Accept

Las distintas cabeceras que influyen en la respuesta se enumeran como un valor separado por comas. Aquí la respuesta depende tanto de la codificación aceptada como del idioma preferido.

Vary: Accept-Encoding, Accept-Language

Una configuración de servicio dinámico entrega distinto HTML a los agentes de usuario móviles y de escritorio. La caché almacena versiones separadas indexadas por la cadena User-Agent completa.

Vary: User-Agent

Combinar Vary con Cache-Control controla tanto qué varía como cuánto tiempo permanece fresca cada variante.

Cache-Control: public, max-age=3600
Vary: Accept-Encoding

Diagnóstico

Los problemas de caché causados por una cabecera Vary ausente o demasiado amplia suelen manifestarse como usuarios que reciben contenido incorrecto.

El CDN sirve la variante almacenada equivocada. Un servidor devuelve contenido distinto según una cabecera de solicitud, pero omite el valor de Vary correspondiente. El CDN almacena la primera respuesta y sirve la misma copia a todos los clientes, sin importar sus cabeceras de solicitud. Añada el nombre de la cabecera pertinente a la lista de Vary. Compruébelo enviando solicitudes con distintos valores de cabecera mediante curl y comparando las cabeceras de respuesta X-Cache o Age: curl -H “Accept-Encoding: gzip” -v https://cdn.example.re/style.css curl -H “Accept-Encoding: br” -v https://cdn.example.re/style.css

Fragmentación de caché por Vary: User-Agent. La cadena User-Agent tiene miles de valores únicos. Incluir User-Agent en la cabecera Vary crea una entrada de caché independiente para casi cada visitante, lo que arruina las tasas de acierto de caché. CDN como Cloudflare y Fastly normalizan el User-Agent en clases de dispositivo. Siempre que sea posible, utilice una cabecera normalizada como Sec-CH-UA-Mobile o una cabecera de tipo de dispositivo propia del CDN en lugar del User-Agent sin procesar.

Vary: * desactiva por completo el almacenamiento en caché. El comodín indica a las cachés que la respuesta varía por factores ajenos a cualquier cabecera de solicitud. La mayoría de las cachés lo tratan como no almacenable en caché y nunca sirven una copia guardada. Elimine Vary: * salvo que la intención sea desactivar todo el almacenamiento en caché del recurso. Si una cabecera de solicitud concreta provoca la variación, indíquela explícitamente.

La ausencia de Vary: Origin provoca envenenamiento de caché de CORS. Un servidor devuelve un valor dinámico de Access-Control-Allow-Origin basado en la cabecera de solicitud Origin, pero no incluye Vary: Origin. Un CDN almacena la respuesta con un origen y entrega la misma cabecera CORS a un origen distinto, lo que hace que los navegadores bloqueen la respuesta. Añada Vary: Origin a toda respuesta que refleje un valor de origen dinámico. Para diagnosticarlo, envíe dos solicitudes curl desde orígenes distintos y compruebe si el Access-Control-Allow-Origin almacenado cambia: curl -H “Origin: https://a.example.re” -v https://api.example.re/data curl -H “Origin: https://b.example.re” -v https://api.example.re/data

Inconsistencias de Vary: Accept-Encoding entre gzip y Brotli. Algunos servidores de origen comprimen con gzip, pero el borde del CDN vuelve a comprimir con Brotli, lo que provoca un desajuste entre la codificación almacenada y la clave de Vary. Asegúrese de que el origen y el CDN coincidan en el comportamiento de codificación. En nginx, configure gzip_vary on; para añadir Vary: Accept-Encoding automáticamente. Al usar Brotli junto con gzip, confirme que ambos módulos añaden el mismo valor de Vary para que la caché almacene entradas separadas por cada codificación.