Cloudflare añade el soporte de Vary en Cache Rules para todos los planes
El encabezado que el sector describe como la parte más fea de HTTP deja de ser un problema: el origen declara qué puede variar y el cliente decide cuánta variación es realmente útil para la caché
Cloudflare ha metido soporte de Vary dentro de sus Cache Rules y lo ha dejado disponible en todos los planes, incluido el gratuito. Hasta ahora el encabezado era una molestia que muchos CDN resolvían ignorándolo o tragándoselo entero, con el riesgo de servir la respuesta equivocada. Ahora el origen sigue declarando qué cabeceras de la petición pueden alterar la respuesta, pero quien administra la zona decide qué hacer con cada una.
Vary es un encabezado de respuesta estándar que avisa a las cachés intermedias de qué campos de la petición influyen en lo que devuelve el origen. Un mismo URL puede tener varias representaciones válidas. El caso de manual: un navegador pide GET /catalog con Accept: text/html y recibe HTML; un cliente de API pide el mismo URL con Accept: application/json y espera JSON. El origen marca Vary: Accept. Sin esa marca, la primera representación que entre en caché se sirve a todo el mundo: si gana el HTML, el parser del cliente de API revienta; si gana el JSON, el navegador recibe una respuesta que no sabe pintar.
El problema no es la corrección, es la cardinalidad
Vary dice qué campos pueden afectar a la respuesta, pero no qué diferencias importan de verdad. Dos peticiones con Accept-Language: en-US, fr;q=0.8 y Accept-Language: fr;q=0.8, en-GB pueden acabar en el mismo cuerpo en inglés, y aun así la caché las guarda como variantes distintas porque compara valores en crudo: distinto orden, distintas etiquetas, espacios y tabuladores que cuentan. El origen sabe que miles de preferencias de idioma colapsan en tres idiomas soportados; la caché, no.
Con varios campos la cosa se multiplica: diez valores en un campo son diez variantes, pero diez valores en tres campos son 1.000 combinaciones. Cloudflare cita un análisis de más de 120 millones de respuestas de casi 50.000 sitios populares en el que casi 3.000 variaban en cuatro o más campos, y algunos en 10, 23 o hasta 47. El resultado es una caché perfectamente correcta y permanentemente fría: entradas idénticas repartidas en trozos con poco tráfico, que se desalojan entre sí, consumen capacidad y mandan más peticiones al origen.
Qué se puede hacer ahora
Las opciones que ya existían siguen ahí: saltarse la caché y dejar que el origen negocie, replicar esa lógica en una cache key personalizada, escribir un Worker o usar el soporte para imágenes. Todas implican renunciar a cachear, duplicar lógica de la aplicación o picar código.
Con Vary en las Cache Rules se elige por cabecera: normalizar las de negociación conocidas, dejar pasar el valor exacto cuando esa diferencia sí importa, o puentear la caché cuando la variación es demasiado impredecible. El encabezado está definido en el RFC 9110.
La pregunta que queda para quien lo configure es cuánta variación de su tráfico real es deliberada y cuánta es ruido de cabeceras. Normalizar de más sirve respuestas incorrectas; de menos, vacía la caché. Ahora la decisión es explícita en lugar de heredada.
