Résumé

  • La fraîcheur HTTP compare l'âge actuel à une durée de fraîcheur ; le champ Age ne fournit pas à lui seul cette décision.
  • Une preuve exploitable relie chronologie, directives, validation, autorisation de servir du contenu périmé et empreinte des octets livrés.

Imaginons un tableau d'exploitation qui lit Age: 20 sur une configuration mise en cache et affiche un voyant vert. Le nombre paraît faible. Pourtant, la réponse porte max-age=10 et le cache la sert comme contenu périmé autorisé pendant une indisponibilité de l'origine. L'en-tête est exact, mais la conclusion ne l'est pas.

La RFC 9111 distingue l'âge de la durée de fraîcheur. Une réponse est fraîche tant que son âge n'a pas dépassé cette durée ; elle est périmée au-delà. Le test oppose donc freshness_lifetime à current_age. Age n'indique ni la durée applicable, ni l'ensemble du calcul de l'âge actuel.

La durée suit sa propre priorité. Dans un cache partagé, s-maxage prime. Viennent ensuite max-age, puis la différence entre Expires et Date. Sans expiration explicite, un cache peut parfois appliquer une heuristique. La norme n'impose pas un algorithme unique : deux déploiements conformes peuvent donc retenir des échéances différentes.

Age est lui-même une estimation calculée. Il représente le temps écoulé depuis la génération ou la dernière validation réussie par l'origine. Le calcul peut associer l'Age reçu au délai de réponse, comparer Date à l'heure de réception, puis ajouter le temps de résidence dans le cache courant. Lorsqu'un cache réutilise une réponse sans validation, il doit émettre l'âge actuel qu'il a calculé.

Cette obligation rend le champ utile, mais n'en fait pas un verdict. Vingt secondes peuvent être fraîches avec une durée de soixante secondes, ou périmées avec une durée de dix secondes. De plus, une réponse périmée peut être servie lorsque le cache est déconnecté ou lorsqu'une directive l'autorise, sauf interdiction applicable telle que no-cache ou must-revalidate.

Il faut donc conserver un reçu de décision de fraîcheur. Ce reçu est une synthèse éditoriale de preuves, et non un élément de protocole défini par l’IETF ou la RFC 9111. Il associe identité et configuration du cache, cible de la requête, réponse stockée et empreinte livrée ; Date, Age reçu et émis, heures de requête et de réponse, temps de résidence ; source de la durée, directives effectives, validation et résultat, autorisation de servir une réponse périmée et décision finale. On peut alors expliquer la réutilisation au lieu de transformer un nombre visible en preuve.

Sources