Résumé

  • Age estime le nombre de secondes écoulées depuis que l’origine a produit ou validé avec succès une réponse. Il ne donne pas l’âge de l’URL, du document, des octets ni du fait représenté.
  • Un cache confronte l’Age reçu à Date, ajoute le délai de la requête et son temps de résidence, puis remplace le champ par un current_age unique lorsqu’il réutilise la réponse sans validation.
  • La fraîcheur vient d’une autre opération : l’âge courant est comparé à une durée issue des directives de cache, d’Expires ou d’une heuristique autorisée. Le nombre ne prouve donc ni validation ni permission de réutiliser.

Une réponse jeune n’est pas forcément un contenu récent

Prenons une page réglementaire écrite trois ans auparavant. Son texte n’a pas changé, mais l’origine vient de confirmer au cache qu’il est toujours valable. Deux minutes plus tard, le lecteur reçoit les mêmes octets avec Age: 120. Le champ n’a pas rajeuni l’histoire : il situe le dernier point de génération ou de validation qui compte pour cette réutilisation.

Le mot « âge » prête à confusion parce qu’il évoque spontanément une propriété de l’objet. Dans HTTP, il qualifie une réponse. La ressource peut avoir une histoire longue, la représentation peut rester stable, et l’entrée locale peut avoir été stockée hier ou revalidée aujourd’hui. Un entier ne raconte aucune de ces biographies.

Le problème résolu était plus étroit. Pour répondre sans solliciter l’origine, un cache doit savoir combien de temps la réponse a déjà passé dans le réseau et les magasins précédents. Cette information doit franchir des frontières techniques et administratives sans supposer que tous les intermédiaires partagent une horloge parfaite.

HTTP/1.0 laissait un trou entre deux caches

La spécification HTTP/1.0 publiée en 1996 connaissait les caches, les dates et l’expiration. Sa grammaire des en-têtes de réponse ne définissait pourtant pas Age, pas plus qu’un calcul commun de l’âge accumulé. Une implémentation pouvait consulter Date, Expires et son instant local de réception, mais elle ignorait combien de temps la réponse avait déjà résidé ailleurs.

Imaginons qu’un cache A conserve une réponse pendant quatre-vingts secondes avant de l’envoyer à B. Si B recommence à zéro, chaque passage offre une nouvelle jeunesse. S’il soustrait seulement Date de son horloge, un décalage entre machines peut fabriquer une valeur négative ou exagérée.

HTTP/1.1 introduisit Age en 1997. Le cache émetteur donnait son estimation, et le suivant pouvait la corriger puis l’allonger. La première définition disait déjà qu’après une validation réussie, la base était l’instant de cette validation, non la réponse originelle. Le champ ne fut donc jamais conçu comme une date de publication déguisée.

Deux mesures imparfaites valent mieux qu’une horloge souveraine

À la réception, le cache peut d’abord calculer un âge apparent avec la date de l’origine :

apparent_age = max(0, response_time - date_value)

Le plancher à zéro empêche une horloge d’origine en avance de produire un temps négatif. La mesure reste toutefois tributaire de deux horloges.

Le cache dispose aussi de la valeur héritée et de son propre intervalle entre l’envoi de la requête et la réception :

response_delay = response_time - request_time

corrected_age_value = age_value + response_delay

Cette deuxième vue repose surtout sur une durée locale. Elle échoue à la baisse si un ancien intermédiaire n’insère pas correctement Age. Pour conserver la prudence en présence de tels chemins, le calcul peut retenir :

corrected_initial_age = max(apparent_age, corrected_age_value)

La spécification actuelle permet d’employer directement la valeur corrigée lorsqu’il n’est pas nécessaire de se protéger contre des caches très anciens. Ce choix montre la nature du mécanisme : il ne cherche pas une heure universelle proclamée vraie, mais une estimation reproductible à partir des indices disponibles.

Le séjour appartient au cache qui l’observe

Une fois la réponse rangée, elle attend. L’amont ne peut connaître la durée de cette attente ; seul le cache local peut la mesurer lorsque survient une nouvelle requête :

resident_time = now - response_time

current_age = corrected_initial_age + resident_time

S’il répond sans validation, le cache doit produire Age et remplacer la valeur antérieure par son âge courant. Il n’ajoute pas une ligne à une chaîne de reçus. Le cache suivant hérite d’un seul nombre, y ajoute le délai observé puis, plus tard, son propre séjour.

Le nombre conserve ainsi la durée et abandonne le trajet. Deux longs séjours ou dix arrêts brefs peuvent aboutir au même résultat. Rien n’indique le nom des intermédiaires, leur ordre, le nombre de sauts ou une garde juridique des octets. Age permet de poursuivre le calcul ; il ne permet pas de reconstruire la provenance.

Cette économie d’information est précisément ce qui rend le champ portable. Le destinataire n’a pas besoin de lire tous les journaux amont. En revanche, un opérateur qui devra expliquer une anomalie doit garder davantage que le champ transmis.

La durée de fraîcheur est un autre compte

Age: 120 ne signifie ni « encore 120 secondes » ni « frais pendant 120 secondes ». L’âge mesure le temps écoulé. La fraîcheur dépend d’une durée autorisée, calculée séparément :

response_is_fresh = (freshness_lifetime > current_age)

Cette durée peut venir de s-maxage pour un cache partagé, de max-age, de l’écart entre Expires et Date, ou d’une heuristique permise. Avec une durée de 300 secondes, un âge de 120 reste frais ; avec 60 secondes, il est périmé au sens du cache.

« Périmé » ne veut pas dire faux, corrompu ou historiquement ancien. Cela signifie que la réutilisation ordinaire sans validation ne satisfait plus la comparaison. Une validation peut rendre la réponse réutilisable. Des directives ou une situation de déconnexion peuvent autoriser certains usages d’une réponse périmée. Inversement, une réponse très jeune peut rester interdite au stockage ou mal correspondre à la requête.

Il faut donc séparer quatre opérations : choisir la bonne réponse stockée, calculer son âge, établir sa durée de fraîcheur et appliquer la règle de réutilisation. Le champ n’en exécute qu’une partie.

La validation change le repère, pas le passé

Après une journée de stockage, un cache peut envoyer une requête conditionnelle. Si l’origine confirme que la représentation reste valable, les mêmes octets peuvent être conservés et l’âge de réponse se rattacher à cette validation. Le document n’a pas été réécrit ; le cache a obtenu un nouveau fondement opérationnel pour le servir.

Une baisse après validation ne prouve donc pas une modification du contenu. Une hausse ne prouve pas l’inaccessibilité de l’origine. Age ne contient ni l’ETag comparé, ni le statut reçu, ni les métadonnées mises à jour. Ces preuves vivent dans d’autres enregistrements.

La présence du champ permet une conclusion limitée : la réponse n’est pas de première main, car un cache l’a produite à partir d’un état stocké. Le champ seul ne révèle pas si ce cache a validé auprès de l’origine pendant cette requête ou s’il s’est appuyé sur une validation antérieure. Son absence ne permet pas la conclusion inverse. Un ancien cache peut l’omettre, une implémentation peut être défectueuse, un système de collecte peut perdre l’en-tête.

Le grand entier est une saturation, pas une observation

La syntaxe demande un entier non négatif en secondes. Une valeur invalide doit être ignorée par un cache. Si une valeur ou un calcul dépasse la capacité de représentation, les RFC récentes conservent la convention historique de 2147483648, ou du plus grand entier positif commode.

Ce nombre, supérieur à 68 ans, joue le rôle d’un infini pratique. Il empêche un dépassement de capacité de revenir en négatif et de faire paraître jeune une réponse extrêmement vieille. Il ne constitue pas une mesure précise de 2 147 483 648 secondes passées en cache.

L’explication exige les termes avant le résultat

Pour auditer une décision, il faut conserver la clé et la variante choisies, les champs Date, Age, Cache-Control, Expires et les validateurs reçus, les trois instants locaux, les valeurs intermédiaires et la provenance de la durée de fraîcheur. Il faut aussi noter la validation, son résultat et le chemin final : frais, validé, périmé mais autorisé, ou échec.

Un tableau de bord limité à l’entier final mélange temps hérité, transit, résidence locale et correction de décalage. Il montre un symptôme mais retire aux acteurs la possibilité d’attribuer la cause.

HTTP n’a pas remplacé ce manque par une institution centrale. L’origine fournit ses métadonnées et ses validateurs. Chaque cache sélectionne, mesure, calcule et assume sa réutilisation. Le suivant vérifie et continue. Le champ coordonne cette opération minimale ; il ne devient ni le propriétaire du temps ni le registre de l’objet.

Sources