4.2.1. Calculating Freshness Lifetime (Calcul de la durée de vie de fraîcheur)

Un cache peut calculer la durée de vie de fraîcheur (notée freshness_lifetime) d'une réponse en utilisant la première correspondance parmi les suivantes :

Si le cache est partagé et que la directive de réponse s-maxage (Section 5.2.2.9) est présente, utiliser sa valeur, ou
Si la directive de réponse max-age (Section 5.2.2.8) est présente, utiliser sa valeur, ou
Si le champ d'en-tête de réponse Expires (Section 5.3) est présent, utiliser sa valeur moins la valeur du champ d'en-tête de réponse Date, ou
Sinon, aucun temps d'expiration explicite n'est présent dans la réponse. Une durée de vie de fraîcheur heuristique pourrait être applicable ; voir Section 4.2.2.

Notez que ce calcul n'est pas vulnérable au décalage d'horloge, car toutes les informations proviennent du serveur d'origine.

Lorsqu'il y a plus d'une valeur présente pour une directive donnée (par exemple, deux champs d'en-tête Expires, plusieurs directives Cache-Control : max-age), la valeur de la directive est considérée comme invalide. Les caches sont encouragés à considérer les réponses qui ont des informations de fraîcheur invalides comme périmées.

4.2.2. Calculating Heuristic Freshness (Calcul de la fraîcheur heuristique)

Puisque les serveurs d'origine ne fournissent pas toujours des temps d'expiration explicites, un cache PEUT (MAY) attribuer un temps d'expiration heuristique lorsqu'un temps explicite n'est pas spécifié, en utilisant des algorithmes qui utilisent d'autres valeurs de champs d'en-tête (telles que le temps Last-Modified) pour estimer un temps d'expiration plausible. Cette spécification ne fournit pas d'algorithmes spécifiques, mais impose des contraintes de pire cas sur leurs résultats.

Un cache NE DOIT PAS (MUST NOT) utiliser d'heuristiques pour déterminer la fraîcheur lorsqu'un temps d'expiration explicite est présent dans la réponse stockée. En raison des exigences de la Section 3, cela signifie que, en pratique, les heuristiques ne peuvent être utilisées que sur des réponses sans fraîcheur explicite dont les codes d'état sont définis comme pouvant être mis en cache par défaut (voir Section 6.1 de [RFC7231]), et ces réponses sans fraîcheur explicite qui ont été marquées comme explicitement pouvant être mises en cache (par exemple, avec une directive de réponse "public").

Si la réponse possède un champ d'en-tête Last-Modified (Section 2.2 de [RFC7232]), les caches sont encouragés à utiliser une valeur d'expiration heuristique qui ne soit pas plus qu'une fraction de l'intervalle depuis ce moment. Un réglage typique de cette fraction pourrait être de 10 %.

Lorsqu'une heuristique est utilisée pour calculer la durée de vie de fraîcheur, un cache DEVRAIT (SHOULD) générer un champ d'en-tête Warning avec un warn-code 113 (voir Section 5.5.4) dans la réponse si son current_age dépasse 24 heures et qu'un tel avertissement n'est pas déjà présent.

Remarque : La Section 13.9 de [RFC2616] interdisait aux caches de calculer la fraîcheur heuristique pour les URI avec des composants de requête (c'est-à-dire ceux contenant '?'). En pratique, cela n'a pas été largement implémenté. Par conséquent, les serveurs d'origine sont encouragés à envoyer des directives explicites (par exemple, Cache-Control : no-cache) s'ils souhaitent empêcher la mise en cache.