Cache du navigateur et routes proxy
Comprendre les clés de cache HTTP, les changements de route, les limites entre caches privés et partagés et le dépannage sûr des réponses mises en cache.
Vous voulez la documentation structurée pour Réseau ?
Cet article fait partie de la bibliothèque éditoriale. Pour les étapes de configuration, la référence et les mises à jour continues, passez directement à la section docs.
Changer de route proxy ne vide pas automatiquement le cache HTTP du navigateur. Si la requête correspond encore à la clé et que la réponse est fraîche, le navigateur peut la réutiliser après le changement. Le proxy modifie le chemin d'une nouvelle requête, mais il ne réécrit pas une entrée déjà stockée. Cette différence compte pour le QA régional, les tests de comptes autorisés et les comparaisons entre routes.
Traitez le cache du navigateur, la route proxy et le cache de l'origine comme trois couches distinctes. Pour chaque réponse, identifiez le propriétaire, notez la route qui l'a obtenue et vérifiez sa fraîcheur avant de conclure. Un changement de route est un changement réseau, pas une commande d'invalidation.
Ce que conserve le cache du navigateur
RFC 9111 définit le cache HTTP. Le navigateur peut conserver une réponse et la réutiliser lorsqu'une requête ultérieure lui correspond. Le cache n'est pas une seconde base de pages, mais un ensemble de représentations, métadonnées et informations de fraîcheur consulté avant le réseau.
La méthode et l'URI commencent la recherche. Une réponse GET est généralement stockable si les directives l'autorisent; une réponse POST demande des règles explicites. Le statut, Vary, l'autorisation, les validateurs, les directives de fraîcheur et le mode de cache de la requête changent le résultat. Le partitionnement et l'éviction sous pression de stockage ajoutent des règles du navigateur.
Cache-Control: max-age et Expires donnent une durée de vie. À son terme, le navigateur peut revalider avec If-None-Match ou If-Modified-Since; un 304 Not Modified conserve le corps existant. no-store demande de ne pas conserver la réponse, tandis que no-cache exige une revalidation avant usage. Ces directives ne sont pas équivalentes.
Vary ajoute des en-têtes de requête à la clé. Une réponse variant selon Accept-Language ou Accept-Encoding ne doit pas servir à une autre valeur. Vary ne crée pas une variation automatique selon l'IP de sortie. Pour un contenu régional, l'origine doit déclarer la dimension dans une conception compatible avec le cache. La route proxy seule n'est pas une clé.
Un cache privé appartient à un profil du navigateur; un CDN ou un proxy de transfert peut servir plusieurs clients et doit respecter les règles de partage, d'autorisation et de confidentialité. Une réponse sûre dans un cache privé ne l'est pas toujours dans un cache partagé. Consultez le guide MDN sur le cache HTTP.
Pourquoi une nouvelle route peut afficher l'ancienne réponse
Après une page chargée par le proxy A, une réponse fraîche peut se trouver dans le cache privé. Si le contexte passe au proxy B et ouvre la même URL, le navigateur peut répondre sans contacter B. Voir la représentation obtenue par A ne prouve donc pas que le changement a échoué.
Si l'entrée est périmée, la revalidation peut passer par B. Un 304 conserve l'ancien corps; une réponse complète le remplace. Un CDN ou un proxy intermédiaire possède parfois son propre cache: le navigateur peut manquer et l'intermédiaire réussir, ou l'inverse. Les redirections, sous-ressources et service workers ajoutent d'autres réponses et magasins. Pour une comparaison régionale, inspectez la séquence complète et la couche qui a fourni chaque ressource.
Une réponse reçue par B peut avoir des métadonnées Vary, Cache-Control ou des validateurs différents. Si la clé ne distingue pas ces représentations, le navigateur peut réutiliser l'une pour l'autre. L'origine doit déclarer ses dimensions; le proxy ne peut pas ajouter une dimension manquante après stockage.
Clés de cache, identité et limites de route
Posez quatre questions: quelle requête est recherchée, quel magasin effectue la recherche, quelle route porterait une requête réseau et qui peut recevoir la réponse. L'URL ne suffit pas. La méthode et certains en-têtes forment la clé; la partition et le profil délimitent le stockage; le proxy ne décide du chemin que lorsqu'une requête est envoyée.
Une réponse avec authentification demande une attention particulière. Authorization empêche souvent le partage sans permission explicite. Les cookies peuvent aussi choisir une représentation, même sans apparaître dans Vary; les données de compte doivent donc recevoir des directives privées adaptées. Réutiliser un profil entre comptes peut transporter d'anciennes réponses malgré un changement de route.
Donnez un propriétaire de cache à chaque objectif de test. Un contexte de compte ne doit pas être réutilisé pour un autre compte ou une autre région sans couvrir volontairement cette continuité. Un nouveau BrowserContext possède normalement ses propres cookies, stockage et cache; changer son proxy ne réinitialise pas ces données.
Une nouvelle adresse de sortie ne constitue pas seule une limite de confidentialité. Elle ne supprime ni cookies, ni localStorage, ni IndexedDB, ni service workers, ni cache HTTP. Vider le cache ne modifie pas non plus le proxy, le résolveur DNS ou le compte. Consultez le modèle de stockage et la configuration proxy.
Pour un contenu régional, utilisez une page de test contrôlée qui affiche une région et un identifiant de représentation. Notez l'URL, le mode de cache, Age s'il existe, ETag, Cache-Control et la route de la requête. Ne conservez pas de contenu privé ni d'identifiants.
Invalidation sûre et dépannage
Commencez par une vérification peu intrusive. Ouvrez une nouvelle page dans le même contexte et lisez le journal. Une mention de cache mémoire ou disque signifie que le proxy n'a pas été contacté. Pour observer la route, utilisez le mode de rechargement documenté qui revalide; un rechargement n'implique pas toujours une requête réseau.
Pour une comparaison propre, créez un BrowserContext neuf avec le proxy attendu et sans état importé. Vérifiez la route avec une ressource contrôlée par votre organisation, puis demandez l'URL de test en ne recueillant que le statut, quelques en-têtes et l'observation de route. Une différence indique probablement un état conservé; un résultat identique oriente vers l'origine ou l'intermédiaire.
Quand une réponse ne doit pas persister, l'origine doit envoyer la directive Cache-Control appropriée. Le nettoyage côté client aide pendant un test, mais ne corrige pas une politique qui place des données privées dans un cache partagé. Utilisez des URL versionnées ou des validateurs pour les ressources, et private ou no-store pour les données de compte.
Vérifiez dans cet ordre: le cache du navigateur et un éventuel service worker; la route et le cache de l'intermédiaire; les dimensions déclarées par l'origine; puis l'équivalence des contextes, URL, méthodes et en-têtes de l'expérience.
N'essayez pas d'empoisonner un cache, d'extraire du contenu privé ou d'inspecter un cache sans autorisation. Utilisez seulement des ressources et comptes contrôlés par votre organisation et arrêtez-vous si le propriétaire de la route ou du stockage n'est pas clair.
Journal de vérification
Gardez une trace courte du contexte, de la route, du mode de cache, de l'identifiant de représentation, du statut du cache et du résultat d'une requête réseau connue. Conservez uniquement les en-têtes nécessaires et retirez cookies, identifiants et corps privés. Si un contexte neuf produit encore un résultat inattendu, transmettez cette trace au responsable de l'origine plutôt que d'effacer l'état à répétition.
Rôle et limites de BotBrowser
BotBrowser peut fournir à chaque BrowserContext une session isolée et une route proxy documentée. Une équipe autorisée peut ainsi comparer le cache dans des contextes séparés et associer chaque requête à sa route. Le proxy par contexte et l'isolation du contexte maintiennent l'état et la route du même cas de test. BotBrowser ne peut pas contrôler Cache-Control ni Vary, ne peut pas ordonner à un cache privé, CDN ou intermédiaire d'oublier une réponse et ne garantit pas qu'un changement de route invalide les caches du navigateur, des service workers, du CDN ou du proxy. L'application et le test restent responsables de la propriété et de l'invalidation. Consultez la documentation du proxy par contexte et de la configuration proxy.
Le propriétaire de l'origine doit décider de la conservation par l'intermédiaire.
Une nouvelle réponse peut modifier l'ETag, l'âge ou les directives. Comparez ces champs avant d'attribuer le changement à la route.
Une entrée périmée peut rester utile: une validation 304 conserve le corps déjà stocké.
Le mode de cache de la requête fait partie de la condition de test et doit être noté avec la méthode.
Une indication de cache mémoire ou disque signifie qu'aucune requête réseau n'a été envoyée pour cette ressource.
Un service worker peut répondre depuis Cache Storage avant la participation du cache HTTP.
Notez la version et l'état d'activation du service worker lorsqu'ils influencent le test.
Les redirections ont leurs propres réponses et peuvent être conservées séparément du document final.
Chaque image, script, police et appel d'API peut suivre une décision de cache différente.
Un CDN peut fournir une réponse partagée même si le navigateur n'a aucune entrée locale.
L'en-tête Age aide à repérer une réponse conservée par un intermédiaire.
L'absence d'Age ne prouve pas qu'aucun intermédiaire n'est intervenu.
Une capture d'écran ne révèle pas quelle couche a fourni chaque ressource.
Les requêtes en cours peuvent finir par l'ancienne route après le changement de proxy.
Attendez la fin de la navigation avant de la prendre comme preuve de la nouvelle route.
Mettez en pause les tâches périodiques liées à l'ancienne route pendant le transfert.
Un contexte neuf sépare généralement ses cookies, son stockage et son cache du contexte précédent.
Changer le proxy d'un contexte existant conserve son état enregistré.
Vider le cache ne supprime pas nécessairement les cookies ni le stockage applicatif.
Effacer toutes les données du site modifie davantage de conditions qu'une invalidation HTTP.
Utilisez une origine de test contrôlée pour vérifier la route sans exposer de données client.
Un identifiant de représentation est plus utile que la conservation du corps d'une page.
Retirez les valeurs d'autorisation, les cookies et les paramètres secrets avant de partager un journal.
Le propriétaire de l'origine doit déclarer chaque dimension qui modifie une représentation.
Un cookie peut sélectionner une variante même s'il n'apparaît pas dans Vary.
Les réponses personnalisées ont besoin de directives qui empêchent le partage involontaire.
Un cache privé ne rend pas privé le cache d'un proxy.
Ne répétez pas une opération qui modifie le serveur avant d'en connaître le résultat.
Un identifiant de requête peut empêcher un second envoi accidentel.
Un 404 peut être une réponse négative stockable et un 5xx peut venir de plusieurs couches.
Associez toujours le code d'état au statut du cache et à la route observée.
Les directives no-cache et no-store décrivent des comportements différents.
Une validation réussie peut actualiser les métadonnées sans télécharger un nouveau corps.
Lorsque la première couche divergente est inconnue, arrêtez le test et demandez une revue au responsable.
Sources publiques
Pour les tests qui incluent des cookies, consultez la documentation de gestion des cookies.
Articles Connexes
Faites passer BotBrowser de la recherche à la production
Utilisez ces guides pour comprendre le modèle, puis passez à la validation multi-plateforme, aux contextes isolés et au déploiement navigateur prêt pour l'échelle.