En bref. Les directives de réponse Cache-Control déterminent si les caches peuvent stocker une réponse et quand ils peuvent la réutiliser ou doivent la valider.

Définition : Cache-Control est un champ d’en-tête HTTP qui transmet des règles aux caches, lesquels stockent des réponses pour les réutiliser. Dans une réponse, ses directives encadrent le stockage, les limites de fraîcheur et la validation auprès du serveur d’origine avant réutilisation.

Points clés

La RFC 9111, HTTP Caching, publiée en juin 2022, définit des directives de réponse, dont max-age, no-cache et no-store.
La RFC 9110, HTTP Semantics définit les requêtes conditionnelles qui permettent à un serveur de confirmer une réponse stockée avec le statut 304 Not Modified.
La RFC 5861, HTTP Cache-Control Extensions for Stale Content définit une réutilisation limitée des réponses périmées (stale) au moyen de stale-while-revalidate et de stale-if-error.

Comment fonctionnent les limites de fraîcheur ?

La durée de fraîcheur (freshness lifetime) est la période pendant laquelle une réponse stockée reste fraîche. L’âge de la réponse mesure le temps écoulé depuis sa génération ou sa validation réussie auprès du serveur d’origine. La RFC 9111 détermine la fraîcheur en comparant cet âge à la durée de fraîcheur.

Un cache privé dessert un seul utilisateur ; un cache partagé en dessert plusieurs. max-age indique une durée en secondes. Pour un cache partagé, s-maxage prime sur max-age et sur l’en-tête Expires. Dans les autres cas, max-age prime sur Expires. En l’absence de durée explicite, une estimation heuristique de la fraîcheur est possible dans les conditions prévues par la RFC.

L’en-tête de réponse Age indique l’âge estimé en secondes. La fraîcheur dépend donc du temps déjà écoulé, y compris du temps passé dans les caches en amont. La réception d’une réponse ne fait pas repartir sa durée de fraîcheur de zéro.

Quelles directives encadrent le stockage et la réutilisation ?

Les directives de réponse de la RFC 9111 distinguent plusieurs mécanismes de contrôle. Les formes présentées ci-dessous sont sans argument :

Cache-Control: no-cache

no-cache autorise le stockage, mais exige une validation réussie avant que la réponse puisse servir à satisfaire une autre requête. no-store interdit à un cache de stocker la requête ou la réponse et de réutiliser cette réponse.

private empêche le stockage dans un cache partagé tout en autorisant un cache privé à stocker la réponse selon les autres règles applicables. must-revalidate impose une validation réussie dès que la réponse devient périmée. Un cache déconnecté doit renvoyer une erreur au lieu de réutiliser cette réponse périmée.

Comment la validation évite-t-elle un transfert complet ?

Un validateur identifie une version stockée ou sa date de modification. Une étiquette d’entité (entity tag) est un identifiant de version transmis dans ETag. La RFC 9110 décrit l’envoi des étiquettes d’entité stockées dans un en-tête de requête If-None-Match. Ses exemples comprennent :

If-None-Match: "xyzzy"

Une version stockée correspondante peut donner lieu à une réponse 304 Not Modified. Cette réponse contient des en-têtes permettant d’identifier ou de mettre à jour la réponse stockée, sans transférer à nouveau son contenu. If-Modified-Since offre une autre méthode, fondée sur une date et utilisant généralement la valeur Last-Modified stockée.

Pour un site web, l’examen de ces en-têtes de requête et de réponse permet de savoir si une nouvelle récupération valide une copie existante ou transfère à nouveau le contenu.

Quand une réponse périmée peut-elle encore être servie ?

Une réponse est périmée lorsqu’elle a atteint sa limite de fraîcheur. La RFC 5861, une RFC de catégorie Informational publiée en mai 2010, donne cet exemple :

Cache-Control: max-age=600, stale-while-revalidate=30

La réponse reste fraîche pendant 600 secondes. Un cache peut ensuite la servir périmée pendant 30 secondes supplémentaires au maximum, tout en tentant une validation en arrière-plan. Cette validation dépend de l’arrivée d’une requête dans cet intervalle.

Le même document définit stale-if-error comme une autorisation limitée de servir une réponse plus ancienne lorsqu’une erreur survient. Ces extensions permettent la réutilisation de réponses périmées dans des conditions précises ; la durée de fraîcheur de la réponse reste inchangée.

Termes associés

Questions fréquentes

max-age force-t-il l’actualisation d’une page à l’écran ?

Non. La RFC 9111 précise que la fraîcheur régit le fonctionnement des caches. Elle ne peut pas forcer votre navigateur à actualiser son affichage ou à recharger une ressource.

stale-while-revalidate programme-t-il une actualisation en l’absence de trafic ?

La RFC 5861 décrit une validation déclenchée par une requête pendant l’intervalle de réutilisation des réponses périmées. Si votre page ne reçoit aucune requête pendant cet intervalle, la validation en arrière-plan peut ne jamais démarrer.

Sources

Vérifiez comment une page se lit pour les moteurs de réponse. Ouvrir l’analyseur de score GEO