Ressources · 99
Cache partagé : tester confidentialité, variantes et invalidation
Accélérer les réponses publiques sans réutiliser celles d’un autre compte et sans conserver des versions périmées.
· 4 min
Ce que ce guide permet
- Classer les réponses
- Inspecter les règles effectives
- Tester la séparation entre utilisateurs
- Exercer la correction d’une version
- Garder un contrôle après changement
Contrôle express
- no-cache signifie-t-il ne rien stocker ?
- Un cookie suffit-il à empêcher le cache partagé ?
- Le taux de hits suffit-il à valider la configuration ?
Méthode pas à pas
- 01
Classer les réponses
Inventoriez pages publiques, réponses personnalisées, téléchargements et erreurs. Pour chaque classe, notez ce qui peut être conservé, par quel composant et pendant combien de temps. Identifiez les réponses variant selon compte, langue ou autorisation.
Livrable : inventaire des réponses et variations.
- 02
Inspecter les règles effectives
Examinez la réponse après le proxy, pas seulement la configuration de l’application. no-cache impose une revalidation avant réutilisation ; no-store interdit le stockage. private limite le stockage aux caches privés. Notez les règles du CDN susceptibles de modifier les en-têtes.
Livrable : captures des en-têtes par parcours.
- 03
Tester la séparation entre utilisateurs
Sur des comptes de test autorisés, demandez la même URL avec deux identités, puis sans session. Utilisez des marqueurs fictifs distincts. Vérifiez corps, téléchargement et réponse conditionnelle. Répétez avec cache froid puis chaud sans placer de donnée réelle dans les preuves.
Livrable : scénario reproductible sans mélange de comptes.
- 04
Exercer la correction d’une version
Publiez une modification de test, puis contrôlez origine, proxy et navigateur. Mesurez le délai jusqu’à la bonne version et testez la purge prévue. Pour les ressources versionnées, vérifiez que le HTML référence bien le nouveau nom ou identifiant.
Livrable : chronologie de propagation et procédure de purge.
- 05
Garder un contrôle après changement
Rejouez les scénarios lors d’une modification de cache, de connexion ou de langue. Suivez les réponses incorrectes et la possibilité de retrait plutôt que le seul taux de hits. Attribuez un responsable au contrôle et à l’invalidation urgente.
Livrable : tests de régression et responsable.
Décider où une réponse peut être réutilisée
Suivez le contenu réellement renvoyé, puis validez séparément confidentialité et retrait.
Réponse personnelle
Empêchez sa réutilisation entre comptes et vérifiez le résultat reçu.
Réponse publique variable
Documentez les variations nécessaires et comparez les réponses correspondantes.
Version corrigée
Exercez la purge et contrôlez la nouvelle version aux différents niveaux.
Cas illustratif : un catalogue public peut être partagé, tandis que le détail du compte doit rester séparé. La rapidité du cache ne valide pas cette séparation.
Quatre situations pour éprouver la politique de cache
Scénarios illustratifs à rejouer avec des comptes et contenus de test autorisés. Ils ne décrivent pas un incident client ni une performance mesurée.
| Situation | Contrôle à effectuer | Décision et preuve attendue |
|---|---|---|
| Page de compte puis même URL sans session | Utiliser deux identités fictives, puis une visite anonyme ; comparer contenu et en-têtes après le proxy, à froid et à chaud. | Tout marqueur d’un autre compte bloque la réutilisation ; conserver la configuration et le résultat de refus, sans donnée personnelle. |
| Deux langues sur une même adresse | Comparer les variantes reçues et le mécanisme qui choisit la langue ; vérifier la clé de cache et les champs Vary réellement utilisés. | La variante doit correspondre à la requête ; corriger la clé ou séparer les adresses, puis rejouer les deux ordres de visite. |
| Document public corrigé à l’origine | Vérifier la version reçue depuis origine, cache partagé et navigateur ; noter ce que la purge touche réellement. | Une purge du CDN ne démontre pas la suppression d’une copie déjà enregistrée ; documenter la propagation et les copies hors contrôle. |
| Réponse conditionnelle après un changement d’identité | Rejouer une requête avec validateur dans un environnement contrôlé et vérifier la représentation effectivement réutilisée. | Un 304 ne contient pas à lui seul la preuve de séparation ; examiner la représentation associée et les permissions. |
Fiche de travail à réutiliser
À compléter avec vos observations autorisées. Ces champs constituent une trame de travail, pas des résultats observés.
| Champ | Information à consigner |
|---|---|
| Classe de réponse | Public, personnel, téléchargement ou erreur |
| Variation | Compte, langue, autorisation et paramètres utiles |
| Test de retrait | Modification, niveaux de cache, résultat et délai |
| Acceptation | Résultat par scénario, preuve conservée et écart bloquant |
Exemple d’application
Situation illustrative
Exemple fictif : un espace client affiche le marqueur COMPTE-A. Une seconde identité et une visite anonyme demandent ensuite la même URL, après remplissage du cache.
Décision et preuve attendue
Si le marqueur apparaît ailleurs, interrompre la réutilisation partagée de cette réponse, corriger les règles puis rejouer les deux ordres de visite. Vérifier également la réponse conditionnelle et conserver une preuve sans donnée personnelle.
Distinguer les mécanismes
| Mécanisme | Utilité | Point de vigilance |
|---|---|---|
| Cache navigateur | Réutilisation par un utilisateur | Tester déconnexion et historique séparément |
| Cache partagé | Réutilisation entre utilisateurs | Exclure les réponses personnelles |
| Ressource versionnée | Conserver une version identifiée | Mettre à jour les références et conserver la cohérence |
Indicateurs de pilotage
| Indicateur | Ce qu’il mesure | Première action |
|---|---|---|
| Séparation | Scénarios entre comptes sans mélange | Bloquer tout écart |
| Propagation | Délai observé jusqu’à la version correcte | Revoir règles et purge |
Erreurs fréquentes
- Tester déconnexion et historique séparément
- Exclure les réponses personnelles
- Mettre à jour les références et conserver la cohérence
Questions fréquentes
no-cache signifie-t-il ne rien stocker ?
Non. Il impose une validation avant réutilisation. no-store concerne l’interdiction de stockage. Vérifiez aussi les règles du proxy.
Un cookie suffit-il à empêcher le cache partagé ?
Ne le supposez pas. Vérifiez les règles réellement appliquées et les réponses reçues avec deux comptes de test.
Le taux de hits suffit-il à valider la configuration ?
Non. Une réponse rapidement réutilisée peut être erronée ou personnelle. Contrôlez contenu, variantes et invalidation.
Références officielles
Date de consultation des références : . La méthode et la fiche de travail proposent des contrôles à adapter à votre contexte ; elles ne constituent pas une certification.
Pour aller plus loin
Analyses associées
