Clés de cache CDN et purge : ce qui identifie un objet mis en cache et comment l'invalider

Ce que c'est

La RFC 9111 définit la clé de cache comme l'information qu'un cache utilise pour choisir une réponse stockée, composée au minimum de la méthode de requête et de l'URI cible ; lorsqu'une réponse stockée porte un en-tête Vary, le cache ne peut la réutiliser que si les champs d'en-tête de requête qui y sont nommés correspondent à ceux de la requête d'origine. Un CDN rend cela concret. La documentation de Cloudflare détaille ce que sa clé de cache par défaut inclut : le schéma, l'hôte, l'URI avec la chaîne de requête, l'en-tête Origin et un ensemble d'en-têtes de substitution de méthode et d'hôte ; des clés de cache personnalisées peuvent ajouter ou retirer des éléments, et la documentation avertit qu'elles peuvent réduire le taux de succès (hit rate) et provoquer un fractionnement du cache (cache sharding). La purge est l'opération inverse : supprimer des objets par URL, par nom d'hôte, par préfixe, en totalité, ou par étiquette (tag). Les surrogate keys de Fastly illustrent le modèle par étiquette : l'origine envoie un en-tête Surrogate-Key nommant une ou plusieurs clés, et la purge d'une clé supprime tous les objets qui lui sont associés ; d'autres CDN proposent des en-têtes d'étiquetage équivalents.

Pourquoi c'est important

Deux catégories de bugs viennent de la clé. Si elle est trop grossière (chaîne de requête ignorée, Accept-Language absent de Vary), les utilisateurs reçoivent les variantes destinées à d'autres. Si elle est trop fine (chaque paramètre de suivi, un cookie de session), le taux de succès s'effondre. La purge échoue silencieusement lorsque l'URL de purge ne correspond pas à la clé stockée : un schéma différent, une barre oblique finale, un caractère encodé ou une chaîne de requête laissent l'objet en place.

Comment l'appliquer

• Décider, chemin par chemin, quelles parties de la requête peuvent modifier la réponse, et n'inclure que celles-ci dans la clé : retirer les paramètres de suivi connus, trier la chaîne de requête, garder Vary court.
• Étiqueter chaque réponse pouvant être mise en cache, depuis l'origine, avec les identifiants des données à partir desquelles elle a été construite (identifiant d'article, identifiant de produit, version de gabarit), et purger par étiquette quand ces données changent.
• Réserver la purge totale aux changements de gabarit ou de code, et s'attendre à un pic de charge sur l'origine ensuite.
• Pour les ressources à empreinte (fingerprinted assets), ne jamais purger ; un nouveau nom constitue une nouvelle clé.
• Après une purge, vérifier avec une requête qui affiche l'en-tête de statut de cache et l'âge de l'objet.

Pièges

Les API de purge ont généralement des limites de débit et un délai de propagation ; un script qui purge une URL par changement sur un site très fréquenté se heurte aux deux. Vary: * ou Vary: Cookie rend les réponses pratiquement impossibles à mettre en cache. Les étiquettes sont attachées au moment du stockage, donc les objets mis en cache avant l'introduction de l'étiquetage ne peuvent pas être purgés par étiquette.