Cloudflare scinde l'en-tête Vary de HTTP en ce qui varie et en l'importance de cette variation

L'en-tête HTTP Vary indique aux caches quels en-têtes de requête peuvent influer sur une réponse, afin qu'un cache ne serve pas le HTML destiné à un navigateur à un client d'API qui demande du JSON. Cloudflare cite une analyse externe portant sur plus de 120 millions de réponses issues de près de 50 000 sites populaires, qui constate que près de 3 000 d'entre elles varient sur quatre champs ou plus, certaines sur 10, 23 ou même 47. Vary est correct, mais pris au pied de la lettre, il peut rendre le cache presque inutile : dix valeurs réparties sur trois champs créent déjà jusqu'à 1 000 variantes, et des en-têtes comme Accept-Language peuvent différer par l'ordre ou le formatage tout en signifiant la même chose pour l'origine.

Le résultat est un cache « parfaitement correct et presque toujours froid » : des réponses identiques octet pour octet se dispersent entre de nombreuses entrées à peine réutilisées, s'évincant mutuellement et renvoyant davantage de requêtes vers l'origine. Les contournements existants — ignorer entièrement le cache, dupliquer la logique de négociation dans un Worker, ou des fonctionnalités étroites comme Vary pour les images — sacrifiaient chacun le cache, dupliquaient la logique applicative ou ne couvraient qu'un seul cas.

Les Cache Rules permettent désormais à l'origine de continuer à déclarer des en-têtes Vary tandis qu'un réglage de règle décide, en-tête par en-tête, s'il faut normaliser les valeurs en un petit ensemble d'équivalences, transmettre les valeurs exactes, ou contourner le cache pour les en-têtes imprévisibles. Deux requêtes Accept-Language, en-US, fr;q=0.8 et fr;q=0.8, en-GB, préférant toutes deux l'anglais, peuvent désormais partager une seule entrée en cache avec la normalisation au lieu de devenir deux variantes, tandis qu'un en-tête qui doit varier exactement peut utiliser la transmission directe. La fonctionnalité est disponible dès aujourd'hui, des offres Free à Enterprise.

Séparer ce qui varie de l'ampleur de variation qui compte

Normaliser Accept et Accept-Language en triant sur la valeur de qualité et en réduisant à un ensemble de formats configuré regroupe en une seule entrée des requêtes différentes octet pour octet mais sémantiquement identiques.

Faire le choix normaliser/transmettre/contourner en-tête par en-tête, et non globalement, permet à un opérateur de traiter Cookie comme non borné (contournement) tout en traitant Accept-Language comme un petit ensemble fermé (normalisation).

Transmettre la valeur d'en-tête normalisée à l'origine, et pas seulement l'utiliser pour la clé de cache, maintient la sélection de réponse de l'origine alignée sur la variante de cache sous laquelle elle est stockée.

Vary: * contourne toujours le cache, car il peut signaler des facteurs extérieurs au message HTTP, comme l'IP du client, qui ont déterminé la réponse, ce qu'aucune règle au niveau des en-têtes ne peut normaliser en toute sécurité.

Lorsqu'un mécanisme de correction explose en gaspillage combinatoire, identifiez les endroits où vous traitez « des octets différents » et « une signification différente » comme une seule et même chose, et donnez à l'opérateur un réglage distinct pour chacun.

Cloudflare indique évaluer si les idées du brouillon IETF Availability Hints, expiré, pourraient permettre aux origines de décrire directement les représentations qu'elles prennent en charge, réduisant le travail manuel de configuration des formats et langues qu'une Cache Rule doit normaliser. L'article présente la répartition actuelle normaliser/transmettre/contourner comme comblant un vide entre les options existantes (contournement total, clés de cache personnalisées ou logique de négociation basée sur un Worker) plutôt que comme une conception définitive.