29. Vary et variantes de représentation

Comprendre le mécanisme

Vary indique des champs de requête ayant contribué au choix de la représentation. Un cache qui réutilise une réponse doit tenir compte des variantes annoncées dans le cadre de son contrat. La langue, certains encodages ou une politique CORS peuvent modifier une réponse. Un champ absent de Vary alors qu’il change le résultat peut conduire à une variante incorrecte. Une liste trop large peut au contraire réduire fortement l’efficacité du cache.

Raisonner et vérifier

N’ajoutez pas mécaniquement tous les champs. Partez du code qui choisit le résultat et des règles du cache intermédiaire. Vary ne remplace pas une politique de confidentialité : annoncer une variation sur Cookie ne suffit pas, à lui seul, à rendre sûre une réponse personnelle publique. Testez variantes, valeur absente, ordre des demandes et invalidation après changement de politique.

Sélection

Vary indique des champs de requête influençant la sélection. La directive participe à la sélection des variantes. Vary nomme des champs de requête qui influencent le choix de représentation. Ce n’est pas une liste de droits ; il aide le cache à distinguer les demandes que le serveur traite différemment.

Langue

Une réponse variant par langue peut annoncer cette dimension. La séparation de variantes n’est pas un chiffrement. Une réponse calculée selon Accept-Language peut annoncer cette dimension. Vérifiez deux langues sur la même URL avec cache chaud pour démontrer que le contenu correspondant est choisi.

Origin

Une politique différente selon Origin peut demander Vary Origin. Le cache doit tenir compte de la variation réelle. Si Access-Control-Allow-Origin varie selon l’origine reçue, le cache doit respecter cette variation pertinente. Sans séparation appropriée, une réponse préparée pour un portail peut être réutilisée dans un autre contexte.

Pas une permission

Vary ne constitue pas seul une autorisation. La sélection de représentation ne vérifie pas la permission. Vary: Cookie ne dit pas qu’un contenu personnel est admissible dans tout cache partagé. Il faut une politique de confidentialité et de stockage complète, avec dimensions et accès effectivement maîtrisés.

Dimension oubliée

Une dimension oubliée peut mélanger des réponses. Les dimensions pertinentes doivent être exactes. Un tenant absent de la clé peut recevoir le contenu d’un autre. Testez précisément une seule différence entre les demandes afin d’identifier la dimension que la sélection doit préserver.

Cardinalité

Des dimensions inutiles peuvent réduire l’efficacité du cache. Une clé trop fragmentée réduit la réutilisation. Ajouter inutilement des champs très variables peut multiplier les entrées et réduire les hits. Choisissez les dimensions requises par la représentation sans supprimer celles qui assurent l’isolation nécessaire.

Comparaison contrôlée

Les tests doivent comparer des requêtes différant sur une dimension. Il faut provoquer la variation à vérifier. Gardez méthode et chemin identiques puis changez un seul header pertinent. Vérifiez contenu et métadonnées afin de distinguer une mauvaise sélection de variante d’un autre changement de comportement.

Intermédiaires

Les intermédiaires doivent respecter le contrat déployé. Les caches métier peuvent utiliser d’autres mécanismes. Les caches réellement déployés doivent comprendre et respecter la stratégie retenue. Une configuration d’application correcte ne suffit pas si le CDN utilise une clé personnalisée incompatible.

Confidentialité complète

La confidentialité demande une politique complète. Le cache privé ou non stockable peut rester nécessaire. Définissez d’abord si la réponse peut être stockée et partagée, puis comment ses variantes sont distinguées. Une clé très détaillée ne justifie pas la conservation de données qui doivent rester non stockées.

Normalisation

Une normalisation doit préserver la signification de la dimension. Une normalisation excessive peut fusionner des représentations distinctes. Normaliser une langue ou une origine peut améliorer la sélection seulement si la signification reste préservée. Une simplification qui fusionne des contextes différents peut recréer une fuite ou servir une mauvaise politique.

Atelier guidé : lire, expliquer et vérifier le code

Access-Control-Allow-Origin: https://portal-a.example.test
Vary: Accept-Language

Cache partagé ; même URL utilisée par plusieurs origines admises.

La réponse varie par origine mais Vary ne montre que la langue dans ce cache partagé. Examinez la stratégie complète et ajoutez la dimension manquante lorsque ce contrat l’exige. Rejouez deux origines admises sur la même URL et vérifiez leur header de partage respectif.

Le cache doit distinguer la variation effectivement annoncée par origine. Un secret ne doit pas être exposé pour construire la politique. Le statut seul ne sépare pas les variantes. Le visuel ne définit pas la clé HTTP.

Travail pratique : Servez deux variantes de langue sur un endpoint de laboratoire cachable puis inversez l’ordre des demandes.

Critères de correction : Vérifiez que chaque appelant reçoit la représentation attendue. Comparez clé effective et champs annoncés, puis testez une origine absente ou refusée. Retirez les variations sans effet plutôt que masquer une conception de cache incohérente.