4 2.Freshness
Une réponse fraîche (Fresh Response) est une réponse dont l'âge n'a pas encore dépassé sa durée de vie de fraîcheur (Freshness Lifetime). À l'inverse, une réponse périmée (Stale Response) est une réponse qui l'a dépassée.
La durée de vie de fraîcheur d'une réponse est la durée entre sa génération par le serveur d'origine et son temps d'expiration. Un temps d'expiration explicite (Explicit Expiration Time) est le moment auquel le serveur d'origine entend qu'une réponse stockée ne peut plus être utilisée par un cache sans validation supplémentaire, tandis qu'un temps d'expiration heuristique (Heuristic Expiration Time) est attribué par un cache lorsqu'aucun temps d'expiration explicite n'est disponible.
L'âge d'une réponse (Age) est le temps qui s'est écoulé depuis qu'elle a été générée par, ou validée avec succès auprès du serveur d'origine.
Lorsqu'une réponse est « fraîche » dans le cache, elle peut être utilisée pour satisfaire des requêtes ultérieures sans contacter le serveur d'origine, améliorant ainsi l'efficacité.
Le mécanisme principal pour déterminer la fraîcheur est que le serveur d'origine fournisse un temps d'expiration explicite dans le futur, en utilisant soit le champ d'en-tête Expires (Section 5.3), soit la directive de réponse max-age (Section 5.2.2.8). En général, les serveurs d'origine attribueront des temps d'expiration explicites futurs aux réponses en partant du principe que la représentation n'est pas susceptible de changer de manière sémantiquement significative avant que le temps d'expiration ne soit atteint.
Si un serveur d'origine souhaite forcer un cache à valider chaque requête, il peut attribuer un temps d'expiration explicite dans le passé pour indiquer que la réponse est déjà périmée. Les caches conformes valideront normalement une réponse en cache périmée avant de la réutiliser pour des requêtes ultérieures (voir Section 4.2.4).
Puisque les serveurs d'origine ne fournissent pas toujours des temps d'expiration explicites, les caches sont également autorisés à utiliser une heuristique pour déterminer un temps d'expiration dans certaines circonstances (voir Section 4.2.2).
Le calcul pour déterminer si une réponse est fraîche est :
response_is_fresh = (freshness_lifetime > current_age)
freshness_lifetime est défini dans la Section 4.2.1 ; current_age est défini dans la Section 4.2.3.
Les clients peuvent envoyer les directives de cache max-age ou min-fresh dans une requête pour contraindre ou assouplir les calculs de fraîcheur pour la réponse correspondante (Section 5.2.1).
Lors du calcul de la fraîcheur, pour éviter les problèmes courants d'analyse des dates :
- Bien que tous les formats de date soient spécifiés comme sensibles à la casse, un destinataire de cache DEVRAIT (SHOULD) faire correspondre les noms de jours, de semaines et de fuseaux horaires de manière insensible à la casse.
- Si l'implémentation interne du temps d'un destinataire de cache a une résolution inférieure à la valeur d'une HTTP-date, le destinataire DOIT (MUST) représenter en interne une date Expires analysée comme le moment le plus proche égal ou antérieur à la valeur reçue.
- Un destinataire de cache NE DOIT PAS (MUST NOT) permettre aux fuseaux horaires locaux d'influencer le calcul ou la comparaison d'un âge ou d'un temps d'expiration.
- Un destinataire de cache DEVRAIT (SHOULD) considérer une date avec une abréviation de zone autre que GMT ou UTC comme invalide pour le calcul de l'expiration.
Notez que la fraîcheur s'applique uniquement au fonctionnement du cache ; elle ne peut pas être utilisée pour forcer un agent utilisateur à actualiser son affichage ou à recharger une ressource. Voir la Section 6 pour une explication de la différence entre les caches et les mécanismes d'historique.