Cloudflare dividió el encabezado Vary de HTTP en qué varía y cuánto importa

El encabezado Vary de HTTP indica a las cachés qué encabezados de solicitud pueden afectar una respuesta, de modo que una caché no sirva el HTML de un navegador a un cliente de API que solicita JSON. Cloudflare cita un análisis externo de más de 120 millones de respuestas en casi 50.000 sitios populares que encontró casi 3.000 que varían en cuatro o más campos, algunos en 10, 23 o incluso 47. Vary es correcto, pero, tomado literalmente, puede hacer que el almacenamiento en caché sea casi inútil: diez valores en tres campos ya crean hasta 1.000 variantes, y encabezados como Accept-Language pueden diferir en orden o formato aunque signifiquen lo mismo para el origen.

El resultado es una caché que es 'perfectamente correcta y casi permanentemente fría': las respuestas idénticas byte a byte se dispersan entre muchas entradas apenas reutilizadas, se desalojan entre sí y empujan más solicitudes de vuelta al origen. Las soluciones alternativas existentes —omitir la caché por completo, duplicar la lógica de negociación en un Worker o funciones limitadas como Vary para imágenes— cada una renunciaba al almacenamiento en caché, duplicaba la lógica de la aplicación o cubría solo un caso.

Las Reglas de caché ahora permiten que el origen siga declarando encabezados Vary mientras que una configuración de regla decide, por encabezado, si normalizar los valores en un pequeño conjunto de equivalencias, dejar pasar los valores exactos o omitir el almacenamiento en caché para encabezados impredecibles. Dos solicitudes Accept-Language, en-US, fr;q=0.8 y fr;q=0.8, en-GB, ambas con preferencia por el inglés, ahora pueden compartir una sola entrada en caché bajo normalización en lugar de convertirse en dos variantes, mientras que un encabezado que debe variar exactamente puede usar el paso directo. Está disponible hoy en los planes Free hasta Enterprise.

Separar qué varía de cuánta variación cuenta

Normalizar Accept y Accept-Language ordenando por valor de calidad y reduciendo a un conjunto configurado de formatos colapsa solicitudes que son diferentes byte a byte pero semánticamente idénticas en una sola entrada.

Hacer la elección normalizar/paso directo/omitir por encabezado, no de forma global, permite que un operador trate Cookie como ilimitado (omitir) mientras trata Accept-Language como un pequeño conjunto cerrado (normalizar).

Reenviar el valor normalizado del encabezado al origen, no solo usarlo para la clave de caché, mantiene la selección de respuesta del origen alineada con la variante de caché en la que se almacena.

Vary: * siempre omite la caché, ya que puede señalar factores fuera del mensaje HTTP, como la IP del cliente, que impulsaron la respuesta, los cuales ninguna regla a nivel de encabezado puede normalizar de forma segura.

Cuando un mecanismo de corrección se convierte en un desperdicio combinatorio, encuentra dónde estás tratando 'bytes diferentes' y 'significado diferente' como lo mismo, y dale al operador un control separado para cada uno.

Cloudflare dice que está evaluando si las ideas del borrador expirado Availability Hints del IETF podrían permitir que los orígenes describan directamente sus representaciones admitidas, reduciendo el trabajo manual de configurar qué formatos e idiomas debería normalizar una Regla de caché. La publicación enmarca la actual división normalizar/paso directo/omitir como el llenado de un vacío entre las opciones existentes (omisión total, claves de caché personalizadas o lógica de negociación basada en Workers) en lugar de como un diseño final.