Calculateur d’expiration du cache HTTP
Saisissez les valeurs Cache-Control, Expires, Date et Age d’une réponse, l’heure de sa réception et l’heure de vérification. Le calculateur donne la durée de fraîcheur, l’âge actuel et indique si la réponse est encore fraîche.
Ce que fait ce calculateur
Il couvre une partie de la RFC 9111, la norme de mise en cache HTTP : le calcul de fraîcheur. C’est la partie qui décide si une réponse stockée peut être réutilisée sans vérification auprès du serveur d’origine. La validation (ETag, If-Modified-Since, 304), Vary et le Cache-Control côté requête ne sont pas traités.
La fraîcheur n’est ni une actualisation ni une suppression
Une réponse périmée signifie seulement qu’un cache ne peut pas la réutiliser sans vérification préalable. Cela ne signifie pas que l’écran du navigateur s’actualise de lui-même, et cela ne signifie pas que le fichier sur le serveur d’origine est modifié ou supprimé. De même, une réponse fraîche ne signifie pas que le fichier sur le serveur n’a pas changé. L’en-tête Expires, dit la norme, « does not imply that the original resource will change or cease to exist at, before, or after that time ». Ce calculateur ne fait que le calcul de temps de la copie en cache.
Durée de fraîcheur et âge actuel
- Durée de fraîcheur : la durée pendant laquelle la réponse peut rester « fraîche ». Elle est fixée par la réponse elle-même (Cache-Control ou Expires) et ne change pas avec le temps.
- Âge actuel : le temps écoulé depuis la génération de la réponse. Il augmente avec le temps.
- Est-elle fraîche ? La réponse n’est fraîche que lorsque la durée de fraîcheur est supérieure à l’âge actuel (lorsqu’ils sont égaux, elle est périmée).
- Fraîcheur restante = durée de fraîcheur − âge actuel.
Quelle valeur fixe la durée de fraîcheur
Selon la section 4.2.1 de la RFC 9111, la première correspondance est utilisée :
| Ordre | Cache partagé (CDN, proxy) | Cache privé (navigateur) |
|---|---|---|
| 1 | s-maxage | (s-maxage n’est pas utilisé) |
| 2 | max-age | max-age |
| 3 | Expires − Date | Expires − Date |
| 4 | Si aucune n’est présente, il n’y a pas d’expiration explicite | Identique |
- Si max-age est présent, Expires est ignoré. Dans un cache partagé, si s-maxage est présent, max-age et Expires sont ignorés (section 5.3).
- Si la même directive apparaît plusieurs fois, la première est utilisée (l’une des approches que la norme autorise).
- Un max-age ou s-maxage qui n’est pas un entier, ou qui est entre guillemets (la norme dit qu’un émetteur ne doit pas générer la forme entre guillemets), est traité comme invalide, et la réponse est considérée comme périmée (durée de fraîcheur 0). Une valeur supérieure à 2 147 483 648 est traitée comme 2 147 483 648 (section 1.2.2).
- Si Expires vaut
0ou une date qui n’existe pas, la réponse est traitée comme déjà expirée (section 5.3). - Quand il n’y a pas d’expiration explicite, la fraîcheur heuristique (par exemple une estimation à partir de Last-Modified) n’est pas calculée. La norme laisse la durée heuristique à l’implémentation.
Comment l’âge actuel est calculé
Les formules viennent de la section 4.2.3 de la RFC 9111 :
- Âge apparent = max(0, heure de réception − Date)
- Âge à la réception = max(âge apparent, en-tête Age + délai de réponse)
- Âge actuel = âge à la réception + temps écoulé depuis la réception
Ce calculateur ne demande pas l’heure d’envoi de la requête : il prend donc le délai de réponse (le temps entre l’envoi de la requête et la réception de la réponse) égal à 0. Sur une connexion à fort délai, l’âge calculé peut être plus petit que l’âge réel. La norme autorise aussi à n’utiliser que l’en-tête Age plus le délai.
Règles de saisie
- Saisissez les dates sous forme d’IMF-fixdate (par exemple
Sun, 06 Nov 1994 08:49:37 GMT) ou d’une heure UTC comme2026-10-21 07:28:00. Tout est en UTC (GMT) ; les fuseaux horaires ne sont pas gérés. L’année doit être comprise entre 1900 et 2100, et les secondes entre 0 et 59 (une seconde intercalaire, 60, n’est pas acceptée). Le nom du jour n’est pas vérifié par rapport à la date. - Les formats RFC 850 et asctime sont des formats que les destinataires HTTP sont censés accepter, mais ce calculateur ne les prend pas en charge. (Cela ne signifie pas qu’ils sont invalides en HTTP. Convertissez la valeur en IMF-fixdate.)
- Si Date est vide, l’heure que vous saisissez dans « Heure de réception de la réponse » est utilisée à la place de Date. La RFC 9110 dit qu’un destinataire qui reçoit une réponse sans Date enregistre l’heure de réception et l’ajoute comme Date. Si cette heure est vide aussi, les calculs qui ont besoin de Date (Expires − Date et l’âge apparent) ne peuvent pas être faits. L’heure actuelle du navigateur n’est jamais utilisée automatiquement ; elle n’est renseignée que lorsque vous appuyez sur le bouton « heure actuelle », dans le champ « Heure de vérification ».
- L’heure à vérifier ne doit pas être antérieure à l’heure de réception de la réponse.
Autres directives Cache-Control
Elles ne sont pas utilisées dans le calcul, mais elles sont affichées comme remarques sur la réutilisation.
- no-store : ne doit pas être stockée. private : un cache partagé ne doit pas la stocker (un navigateur le peut).
- no-cache (sans arguments) : même fraîche, elle ne peut pas être réutilisée sans validation.
- must-revalidate : une fois périmée, elle ne doit pas être utilisée sans validation. proxy-revalidate : pareil, mais cela ne s’applique pas à un cache privé.
- public : autorise explicitement le stockage.
- immutable (RFC 8246), stale-while-revalidate et stale-if-error (RFC 5861) sont en dehors de la RFC 9111. Ils sont reconnus mais non utilisés dans le calcul.
Exemples
| Saisie | Résultat |
|---|---|
| max-age=3600, sans Age, 1 800 s après la réception | Durée de fraîcheur 3 600 s, âge actuel 1 800 s, 1 800 s restantes (fraîche) |
| Idem, à exactement 3 600 s | Âge actuel 3 600 s. Il est égal à la durée de fraîcheur : elle est donc périmée |
| max-age=3600, Age=600, tout juste reçue | Âge actuel 600 s, 3 000 s restantes |
| Cache partagé avec s-maxage=60, max-age=3600 | Durée de fraîcheur 60 s (max-age est ignoré) |
À savoir
- C’est un calcul fondé sur la norme. Les navigateurs et CDN réels ne se comportent pas toujours exactement comme le décrit la norme. Des actions comme un rechargement forcé et des réglages propres à un CDN peuvent donner des résultats différents. Le comportement d’un produit particulier n’est pas garanti.
- La fraîcheur heuristique, la validation, Vary, les directives de requête et l’addition de plusieurs caches ne sont pas traitées.
Sources et vérifications
Les éléments suivants ont été vérifiés dans le texte intégral des normes le 1er novembre 2026 :
- RFC 9111, « HTTP Caching » : https://www.rfc-editor.org/rfc/rfc9111 (sections 1.2.2, 4.2.1, 4.2.3, 5.1, 5.2.2 et 5.3, y compris le test de fraîcheur
freshness_lifetime > current_age) - RFC 9110, « HTTP Semantics » : https://www.rfc-editor.org/rfc/rfc9110 (sections 5.6.7 et 6.6.1)
Ce calculateur suit ces sections pour la fraîcheur uniquement. Réussir ce calcul ne revient pas à affirmer qu’un produit ou un serveur est conforme à la norme.
Questions fréquentes
Que se passe-t-il quand max-age et Expires sont tous deux présents ?
max-age est prioritaire et Expires est ignoré (RFC 9111, section 5.3).
s-maxage s’applique-t-il à un navigateur ?
s-maxage est une directive pour les caches partagés. Un cache privé (un navigateur) ne l’utilise pas.
Qu’est-ce que l’en-tête Age ?
C’est le nombre de secondes, écrit par un cache intermédiaire, depuis la génération de la réponse ou sa dernière vérification auprès de l’origine. Ce calculateur l’utilise pour trouver l’âge actuel.
Une réponse périmée disparaît-elle ou s’actualise-t-elle d’elle-même ?
Non. Périmée signifie seulement qu’un cache doit vérifier avant de la réutiliser. Cela n’actualise pas l’écran et ne change rien sur le serveur d’origine.
Comment puis-je vérifier une heure ?
Le convertisseur d’horodatage Unix et le calculateur d’expression cron peuvent aider.