no-cache ne veut pas dire « ne pas mettre en cache ». Sept sur dix-sept atteignent un CDN.

L'en-tête

Envoyé dans une

Valeur de Cache-Control

Ajoutez ou retirez une directive

Ce que dit cet en-tête

Rien ici ne s'adresse à un cache partagé. Seul le navigateur du visiteur reçoit des instructions.

no-cache est présent : une copie stockée doit être revalidée avant d'être réutilisée.

Attention : no-cache n'empêche PAS le stockage. La réponse est bien stockée ; elle ne peut simplement pas être resservie sans vous consulter d'abord. La directive qui interdit de stocker est no-store.

Toutes les directives présentes valent pour ce côté de l'échange.

Ce que définit la spécification

directives: 17
mentionnent un cache partagé: 7
mentionnent les deux sortes: 2
ont une valeur facultative: 3

La RFC 9111 distingue le cache partagé — un CDN, un proxy inverse, tout ce qui sert plus d'une personne — du cache privé, celui du navigateur. Sept des dix-sept directives nomment un cache partagé dans leur propre définition, et deux seulement nomment les deux. Le registre IANA de ces directives n'en consigne rien : des noms, des références, et rien sur le comportement — d'où la lecture de la prose de la spécification par cette page.

Sept directives prennent une valeur, mais quatre seulement l'exigent. no-cache, private et max-stale ont chacune une forme valide sans aucune valeur, et pour no-cache les deux formes ne disent pas la même chose : avec un nom d'en-tête elle ne restreint que cet en-tête ; sans lui elle porte sur toute la réponse.

Les 17 directives

Rechercher

Affichage 17 / 17

Directive	Envoyée dans	Valeur	Cache partagé	La RFC 9111 dit
max-age	Requête	Obligatoire	Non	5.2.1.1 The max-age request directive indicates that the client prefers a response whose age is less than or equal to the specified number of seconds. Unless the max-stale request directive is also present, the client does not wish to receive a stale response.
max-stale	Requête	Facultative	Non	5.2.1.2 The max-stale request directive indicates that the client will accept a response that has exceeded its freshness lifetime. If a value is present, then the client is willing to accept a response that has exceeded its freshness lifetime by no more than the specified number of seconds.
min-fresh	Requête	Obligatoire	Non	5.2.1.3 The min-fresh request directive indicates that the client prefers a response whose freshness lifetime is no less than its current age plus the specified time in seconds. That is, the client wants a response that will still be fresh for at least the specified number of seconds.
no-cache	Requête	Aucune	Non	5.2.1.4 The no-cache request directive indicates that the client prefers a stored response not be used to satisfy the request without successful validation on the origin server.
no-store	Requête	Aucune	Oui	5.2.1.5 The no-store request directive indicates that a cache MUST NOT store any part of either this request or any response to it. This directive applies to both private and shared caches.
no-transform	Requête	Aucune	Non	5.2.1.6 The no-transform request directive indicates that the client is asking for intermediaries to avoid transforming the content, as defined in Section 7.7 of [HTTP].
only-if-cached	Requête	Aucune	Non	5.2.1.7 The only-if-cached request directive indicates that the client only wishes to obtain a stored response. Caches that honor this request directive SHOULD, upon receiving it, respond with either a stored response consistent with the other constraints of the request or a 504 (Gateway Timeout) status code. 5.2.2.
max-age	Réponse	Obligatoire	Non	5.2.2.1 The max-age response directive indicates that the response is to be considered stale after its age is greater than the specified number of seconds. This directive uses the token form of the argument syntax: e.g., 'max-age=5' not 'max-age="5"'. A sender MUST NOT generate the quoted-string form.
must-revalidate	Réponse	Aucune	Oui	5.2.2.2 The must-revalidate response directive indicates that once the response has become stale, a cache MUST NOT reuse that response to satisfy another request until it has been successfully validated by the origin, as defined by Section 4.3.
must-understand	Réponse	Aucune	Non	5.2.2.3 The must-understand response directive limits caching of the response to a cache that understands and conforms to the requirements for that response's status code. A response that contains the must-understand directive SHOULD also contain the no-store directive.
no-cache	Réponse	Facultative	Non	5.2.2.4 The no-cache response directive, in its unqualified form (without an argument), indicates that the response MUST NOT be used to satisfy any other request without forwarding it for validation and receiving a successful response; see Section 4.3.
no-store	Réponse	Aucune	Oui	5.2.2.5 The no-store response directive indicates that a cache MUST NOT store any part of either the immediate request or the response and MUST NOT use the response to satisfy any other request. This directive applies to both private and shared caches.
no-transform	Réponse	Aucune	Non	5.2.2.6 The no-transform response directive indicates that an intermediary (regardless of whether it implements a cache) MUST NOT transform the content, as defined in Section 7.7 of [HTTP].
private	Réponse	Facultative	Oui	5.2.2.7 The unqualified private response directive indicates that a shared cache MUST NOT store the response (i.e., the response is intended for a single user).
proxy-revalidate	Réponse	Aucune	Oui	5.2.2.8 The proxy-revalidate response directive indicates that once the response has become stale, a shared cache MUST NOT reuse that response to satisfy another request until it has been successfully validated by the origin, as defined by Section 4.3.
public	Réponse	Aucune	Oui	5.2.2.9 The public response directive indicates that a cache MAY store the response even if it would otherwise be prohibited, subject to the constraints defined in Section 3. In other words, public explicitly marks the response as cacheable.
s-maxage	Réponse	Obligatoire	Oui	5.2.2.10 The s-maxage response directive indicates that, for a shared cache, the maximum age specified by this directive overrides the maximum age specified by either the max-age directive or the Expires header field.

Chaque définition ci-dessous est citée mot pour mot de la RFC 9111, section 5.2, avec son numéro de section. Rien n'est envoyé : l'analyse a lieu dans cet onglet. Instantané pris le 2026-08-03

Aussi disponible en : English · Español · Português · العربية

En-tête Cache-Control : toutes les directives et ce que voit un CDN

Choisissez des directives et obtenez un en-tête, ou collez-en un et découvrez ce qu'il dit réellement à un navigateur et à un cache partagé.

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

Cache-Control est la façon dont un serveur indique aux caches ce qu'ils peuvent faire d'une réponse, et dont un client leur indique ce qu'il acceptera. La RFC 9111 en définit dix-sept directives : sept qui vont sur une requête et dix qui vont sur une réponse. Quatre noms figurent des deux côtés — max-age, no-cache, no-store et no-transform — et signifient des choses différentes selon le sens dans lequel le message circule.

La distinction la plus importante ne figure pas dans la liste des directives. La RFC 9111 sépare le cache partagé, c'est-à-dire un CDN ou un proxy inverse ou tout ce qui sert plus d'une personne, du cache privé, celui du navigateur. Sept des dix-sept directives nomment un cache partagé dans leur définition et deux seulement nomment les deux. L'IANA tient un registre de ces directives et n'en consigne rien : des noms, des références, et rien sur le comportement — cette page lit donc la prose de la spécification.

C'est pourquoi un en-tête peut sembler complet et ne rien dire à votre CDN. max-age s'adresse à n'importe quel cache ; s-maxage, public, private et proxy-revalidate sont celles qui visent expressément le cache partagé.

Comment l'utiliser

Choisissez le côté. Réponse est le cas habituel : ce que votre serveur envoie. Requête est ce qu'envoie un navigateur ou un client, avec un autre jeu de sept directives.
Cliquez des directives ou saisissez l'en-tête directement. Les boutons et le champ de texte ne font qu'un : activer une directive réécrit le champ, et modifier le champ met à jour les boutons.
Lisez le verdict, pas seulement la chaîne. On vous dit si quelque chose atteint un cache partagé, ce qui est réellement interdit, et quelles directives posent problème — avec la formulation même de la spécification en dessous.

no-cache ne veut pas dire « ne pas mettre en cache »

C'est le contresens le plus lourd de conséquences de tout l'en-tête, et la RFC 9111 tranche sans détour. La forme de réponse de no-cache signifie que la réponse « NE DOIT PAS être utilisée pour satisfaire une autre requête sans être transmise pour validation ». La réponse est bel et bien stockée. Elle ne peut simplement pas être resservie sans consulter votre serveur au préalable, ce qui est en général exactement ce que l'on veut et pas du tout ce que l'on croit demander.

La directive qui interdit de stocker, c'est no-store : un cache « NE DOIT PAS stocker la moindre partie » de la requête ni de la réponse. Si vous avez des données sensibles et que vous avez pris no-cache, vous avez pris la mauvaise. Cette page rapporte les deux comme des constats distincts plutôt que de les confondre, et le signale sur-le-champ lorsqu'un en-tête porte no-cache sans no-store.

Une subtilité voisine mérite d'être connue : no-cache peut prendre un nom d'en-tête comme valeur, et les deux formes diffèrent. Sans valeur, elle porte sur toute la réponse. Avec un nom d'en-tête, elle ne restreint que celui-là, le reste de la réponse restant réutilisable. Sept directives prennent une valeur et quatre seulement l'exigent : no-cache, private et max-stale ont chacune une forme parfaitement valide sans rien derrière.

Ce que cette page ne vous dira pas

Elle ne vous dira pas ce que fait votre CDN en particulier. Les directives sont ce que la spécification déclare qu'un cache conforme doit et peut faire ; chaque CDN commercial superpose sa propre configuration, ses directives maison et ses réglages par défaut, et plusieurs honorent des extensions non normalisées que cette page ignore. Une directive signalée comme atteignant un cache partagé vous dit que la norme s'adresse à lui, pas que votre fournisseur l'implémente comme vous l'imaginez.

Elle ne couvre par ailleurs que Cache-Control. La fraîcheur se décide aussi ailleurs — Expires, Age, ETag et Last-Modified y participent tous — et une réponse dépourvue de Cache-Control peut encore être mise en cache par heuristique. Vérifier un en-tête est une étape nécessaire, pas un audit complet.

Enfin, elle rapporte les mots de la spécification, non des conseils. Il n'y a pas d'en-tête recommandé ici, car le bon dépend du caractère personnalisé de la ressource, du fait que son URL soit versionnée, et de la vitesse à laquelle un changement doit atteindre les gens. Ce que la page peut faire, c'est vérifier que l'en-tête choisi signifie bien ce que vous croyez.

Pourquoi est-ce gratuit ?

La table des directives tient en quelques kilo-octets qui voyagent avec la page, et l'analyse a lieu dans votre propre navigateur. Rien de ce que vous tapez n'est envoyé, rien n'est journalisé, et il n'y a aucun compte à créer.

Sans inscription, sans limite, et sans filigrane sur ce que vous copiez.