Cloudflare ya soporta el header Vary en Cache Rules

Qué es el header Vary y por qué se ganó el título de «lo más feo de HTTP»

Cloudflare acaba de activar soporte nativo del header HTTP Vary dentro de Cache Rules, disponible en los planes Free, Pro, Business y Enterprise desde el panel y la API. Es una de esas funcionalidades del estándar que llevan años generando fricción silenciosa entre los caches de los CDNs y las aplicaciones reales, y que para muchos founders solo aparece en el radar cuando algo se rompe.

Vary es un header de respuesta estándar que le indica a los caches intermedios qué campos del request pueden afectar la respuesta. Si tu servidor responde con Vary: Accept, le está diciendo al cache: «no trates la URL como única clave; el header Accept también cuenta». El protocolo tiene otro Vary: Accept-Language para distinguir variantes de idioma, y así con cualquier campo de negociación.

El problema es que Vary no le dice al cache qué diferencias importan realmente. Solo declara qué campos pueden variar, y deja al cache adivinando si dos valores ligeramente distintos del mismo campo deben contar como variantes separadas o como la misma respuesta. La propia documentación recoge la descripción del mecanismo como «horrible y parcheado», con una «bastante pésima interoperabilidad» entre intermediarios. La reacción típica de ingenieros que se lo encuentran por primera vez, según la misma fuente, es «retroceder despacio con las manos en alto».

👥 ¿Quieres ir más allá de la noticia?

En nuestra comunidad discutimos las tendencias, compartimos oportunidades y nos ayudamos entre emprendedores. Sin humo, solo acción.

👥 Unirme a la comunidad

Para un founder, el resultado es binario: o el cache ignora Vary y sirve el contenido incorrecto a un cliente, o trata cada valor crudo como único y termina con miles de variantes que casi nunca se reutilizan. Cualquiera de los dos rompe el propósito del cache.

Cuán grave es realmente el problema

Cloudflare no lo plantea como teoría: publicó, junto al anuncio, un análisis de más de 120 millones de respuestas obtenidas de casi 50.000 sitios populares. El hallazgo central: cerca de 3.000 sitios variaban en cuatro o más campos simultáneamente, y algunos lo hacían en 10, 23 e incluso 47 campos a la vez.

El efecto compuesto es claro. Diez valores posibles en un campo generan diez variantes. Diez valores en tres campos pueden generar 1.000 combinaciones. En headers reales la cardinalidad es mucho peor: User-Agent tiene miles de valores, las cookies pueden ser únicas por visitante, y los headers de preferencia varían en orden, formato (espacios y tabulaciones importan) y valores de calidad. El cache termina técnicamente correcto pero prácticamente frío: respuestas idénticas desperdigadas en entradas que reciben demasiado poco tráfico como para mantenerse calientes, que se expulsan unas a otras y que degradan el hit ratio hasta volverlo inútil.

En sitios globales que sirven idiomas, formatos de imagen (avif, webp), encodings (gzip, br, zstd) o versiones regionales desde la misma URL, esta fragmentación marca la diferencia entre un cache que ahorra costos y uno que solo existe en el diagrama de arquitectura.

Qué cambia con la implementación de Cloudflare

La propuesta parte de una separación de responsabilidades que el estándar nunca hizo explícita: el origen declara qué campos pueden variar; Cloudflare decide cómo manejar cada uno. La nueva configuración dentro de Cache Rules ofrece tres acciones por header.

normalize (recomendada como default): Cloudflare normaliza valores equivalentes antes de elegir la variante cacheada. Para Accept, Accept-Language y Accept-Encoding aplica reglas específicas (minúsculas, orden por calidad, colapso de tags regionales a su base, filtrado de parámetros con q=0). Para otros headers, limpia espacios opcionales y combina líneas repetidas en orden, preservando capitalización y espacios interiores. Dos requests con en-US, fr;q=0.8 y fr;q=0.8, en-GB colapsan a en,fr y comparten la misma entrada de cache.
passthrough: usa los bytes crudos del header como clave de cache, preservando capitalización, espacios, orden y duplicados. Sirve cuando el origen necesita distinguir entre valores exactos.
bypass: no cachea la respuesta cuando el origen incluye ese header en Vary. Útil para headers personalizados como Cookie o User-Agent, donde la cardinalidad destroza el cache.

La acción se configura individualmente por header o se hereda del default de la regla. Vary: * (que significa «cualquier cosa puede afectar la respuesta, incluso información fuera del mensaje HTTP como la IP del cliente») sigue sin ser cacheable: Cloudflare no puede asumir reutilización sin volver a contactar al origen.

La configuración se hace desde el panel en Caching > Cache Rules, vía la Rulesets API en la fase http_request_cache_settings, o en Terraform, según la documentación oficial.

¿Qué significa esto para tu startup?

Si tu producto sirve el mismo endpoint en varios formatos, idiomas o regiones, este cambio elimina la falsa elección entre cache rápido pero incorrecto, o cache correcto pero inútil. Tres escenarios donde el beneficio aparece rápido:

SaaS multi-país: un endpoint /dashboard que adapta la UI según Accept-Language (es-AR, es-MX, es-ES). Con normalize configurado a ["es", "en", "pt"], las tres variantes colapsan en una sola entrada de cache.
E-commerce con variantes regionales: /producto/123 que cambia precio o stock según un header custom tipo X-Region. Defines bypass para el header regional (porque cada región es única) y normalize para Accept-Language. Idioma cachea, región no.
API multi-formato: /catalog que responde HTML o JSON según Accept. Defines normalize con media_types: ["text/html", "application/json"] y reduces miles de combinaciones a unas pocas estables.

El beneficio operativo se nota en tres KPIs que cualquier founder mira: carga al origen (menos requests que vuelven a tu servidor), latencia p95 (más respuestas servidas desde el edge) y costo de egress (menos bytes saliendo de AWS, GCP o Azure). Cloudflare viene reforzando esta superficie de control en los últimos meses; según InfoQ, también lanzó en agosto las Cache Response Rules, que operan después de que el origen responde y permiten limpiar headers como Set-Cookie o reescribir directivas Cache-Control antes de almacenar.

Acciones concretas que puedes tomar esta semana

Audita tu uso actual de Vary. Revisa qué headers tienes declarados en Vary hoy en tu CDN o en el header de respuesta del origen. Cualquier header con cardinalidad alta (cookies, User-Agent completo, tokens de session) debería mapear a bypass, no a normalize. Sin este paso, el nuevo motor no hará magia.
Empieza con normalize como default. Según la propia guía de Cloudflare, es el punto de partida recomendado. Configura explícitamente solo los headers donde necesites passthrough (el origen distingue entre valores exactos) o bypass (el header es personalizado o de muy alta cardinalidad).
Prueba con un endpoint real antes del rollout. Envía requests con diferentes valores de Accept-Language desde el mismo cliente, inspecciona el header CF-Cache-Status (debería mostrar HIT después del primer request) y verifica que el contenido servido sea el esperado. Cualquier MISS persistente o respuesta inesperada en esta prueba señala un problema de configuración o un origen que devuelve Vary de forma inconsistente entre respuestas.

Un detalle que muchos olvidan: cambiar la configuración de Vary no purga automáticamente el contenido cacheado. Las entradas antiguas siguen vivas hasta expirar, así que convive planificar un purge o esperar al TTL si necesitas que el cambio entre en vigor de inmediato.