Qu’est-ce que l’en-tête Cache-Control ?

Cache-Control est un en-tête de requête ou de réponse HTTP dont les directives régissent le stockage, la fraîcheur, la revalidation et la réutilisation par les caches. Des directives différentes peuvent s’appliquer aux navigateurs et aux intermédiaires partagés.

Cache-Control communique une politique au moyen de directives séparées par des virgules dans une requête ou une réponse HTTP. Les directives de fraîcheur déterminent quand la réutilisation peut avoir lieu sans contacter l’origine, tandis que les directives de stockage, de validation et de portée limitent ce que les caches privés et partagés peuvent conserver ou servir. Les directives de réponse s’imposent à un cache conforme, tandis que les directives de requête sont indicatives. Un CDN peut ignorer celles qui permettraient à un client de forcer un accès à l’origine : Google Cloud CDN, par exemple, ignore no-cache et max-age dans les requêtes. L’en-tête s’adresse simultanément à tous les caches sur le chemin et ne peut pas en cibler un en particulier. C’est pourquoi la RFC 9213 définit CDN-Cache-Control, un en-tête de réponse distinct utilisant les mêmes directives, qu’un cache CDN compatible utilise à la place de Cache-Control.

no-cache autorise le stockage d’une réponse, mais exige une validation réussie auprès de l’origine avant chaque réutilisation ; no-store indique à chaque cache, privé ou partagé, de ne pas stocker du tout la réponse. La RFC 9111 ajoute que no-store n’est pas un mécanisme fiable ou suffisant pour garantir la confidentialité : il s’agit donc d’une instruction de mise en cache, qui ne remplace pas le contrôle d’accès.
max-age définit la durée de fraîcheur pour tous les caches ; s-maxage la remplace dans les caches partagés tels que les CDN et est ignoré par les navigateurs. Pour un fichier dont l’URL change à chaque modification du contenu, MDN propose d’associer une longue durée max-age (un an dans son exemple) à immutable, qui indique que la réponse ne sera pas mise à jour tant qu’elle est fraîche. s-maxage porte également le sens de proxy-revalidate : une fois la réponse périmée, un cache partagé doit la revalider avant de la réutiliser. Lorsque la fonction Origin Cache Control est activée, ce qui est le cas par défaut avec ses forfaits Free, Pro et Business, Cloudflare ne sert pas de réponse périmée comportant s-maxage. Google Cloud CDN documente le même comportement ; stale-while-revalidate n’a donc aucun effet en complément dans ces configurations. La solution de contournement documentée par Cloudflare consiste à utiliser max-age avec stale-while-revalidate, ainsi qu’une règle TTL distincte pour les caches en périphérie.
private empêche le stockage par les caches partagés, mais autorise le cache propre au navigateur ; ce n’est donc pas une désactivation de la mise en cache. Cette directive doit être définie explicitement sur les réponses personnalisées. HTTP interdit de lui-même le stockage d’une réponse dans les caches partagés uniquement lorsque la requête contient un en-tête Authorization. Même dans ce cas, public, s-maxage ou must-revalidate lève cette restriction. Une session transmise dans un en-tête de requête Cookie ne déclenche aucune règle de ce type, et la RFC 9111 précise qu’un en-tête de réponse Set-Cookie n’empêche pas la mise en cache. Google Cloud CDN refuse de mettre en cache une réponse comportant Set-Cookie. Au niveau de cache par défaut, Cloudflare la refuse également lorsque la fonction Origin Cache Control est activée. Lorsque cette fonction est désactivée, Cloudflare peut toutefois mettre la réponse en cache après en avoir retiré l’en-tête Set-Cookie. Dans les deux cas, il s’agit du comportement du fournisseur, pas d’une règle de HTTP.
Une réponse sans Cache-Control peut tout de même être mise en cache. La RFC 9111 permet à un cache d’attribuer une durée de validité heuristique à une réponse admissible à la mise en cache heuristique sans expiration explicite. Elle recommande de ne pas dépasser une fraction du temps écoulé depuis Last-Modified. Les CDN appliquent leur propre durée de validité par défaut lorsque le serveur d’origine n’en fournit aucune. Les erreurs suivent les mêmes règles : une réponse finale avec une durée de fraîcheur explicite peut être stockée. Ainsi, une réponse 5xx accompagnée de la longue durée de validité max-age utilisée pour les réponses réussies peut être stockée et renvoyée par un cache en aval, même si les codes d’état qu’un CDN donné stocke dépendent du fournisseur. Envoyez no-store pour toute réponse qui ne doit pas être mise en cache, et n’appliquez pas aux réponses d’erreur les durées de validité prévues pour les réponses réussies. Un CDN peut aussi mettre les erreurs en cache selon un réglage qui lui est propre et que l’en-tête ne désactive pas : Amazon CloudFront ignore no-store, no-cache et private pour les réponses 500, 502, 503 et 504, et les met en cache pendant la durée définie par Error Caching Minimum TTL, qui se règle par code d’état et vaut par défaut 10 secondes. Il ne met pas ces erreurs en cache lorsque le comportement de cache utilise la politique de cache gérée CachingDisabled.
L’en-tête du serveur d’origine n’a pas toujours le dernier mot en périphérie. Amazon CloudFront utilise le TTL minimal de la politique de cache lorsqu’il est supérieur à 0, même si le serveur d’origine a envoyé no-cache, no-store ou private. Une règle Edge Cache TTL de Cloudflare prend le pas sur s-maxage et les directives de revalidation, et le mode FORCE_CACHE_ALL de Google Cloud CDN met en cache les réponses réussies indépendamment des directives du serveur d’origine. Vérifiez les réglages de TTL et de remplacement des directives du CDN avant de vous fier à une directive pour empêcher le stockage d’une réponse dans un cache partagé.

Définissez Cache-Control selon que la réponse est publique, privée, immuable ou fréquemment mise à jour. Des directives contradictoires ou trop permissives peuvent exposer des données privées ou conserver des médias périmés.

Lorsque Transloadit diffuse un fichier transformé via le Smart CDN, le Robot /file/serve définit l’en-tête Cache-Control du résultat, avec une durée de validité pour le navigateur dans max-age et une durée distincte pour les caches partagés dans s-maxage. Le paramètre cache_duration du Robot attribue une même valeur aux deux directives, et son paramètre headers fusionne vos propres valeurs d’en-tête avec les valeurs par défaut en leur donnant priorité. Pour les URL signées du Smart CDN, la durée effective de mise en cache est également limitée par la durée de validité restante de la signature.

La page du Robot indique les durées de validité par défaut actuelles.

Explorer les capacités de diffusion de Transloadit

Qu’est-ce que l’en-tête Cache-Control ?

Fonctionnement de l’en-tête Cache-Control

Points clés

Quand l’en-tête Cache-Control est important

Comment Transloadit vous aide à gérer l’en-tête Cache-Control

Références

Transformer vos connaissances sur les médias en une chaîne de traitement opérationnelle