2. Overview of Cache Operation
Un fonctionnement correct du cache préserve la sémantique des transferts HTTP tout en réduisant la transmission d'informations déjà détenues dans le cache. Voir la Section 3 pour les détails sur la façon dont un cache peut déterminer quelles réponses sont mises en cache et la Section 4 pour les détails sur la construction de réponses à partir d'entrées de cache. Cette section fournit un aperçu de la manière dont les caches sélectionnent et mettent à jour les réponses stockées.
Bien que la mise en cache soit une fonctionnalité entièrement OPTIONNELLE (OPTIONAL) de HTTP, on peut supposer que la réutilisation d'une réponse mise en cache est souhaitable et que cette réutilisation est le comportement par défaut lorsqu'aucune exigence ou configuration locale ne l'empêche. Par conséquent, les exigences de cache HTTP se concentrent sur la prévention du stockage par un cache d'une réponse non réutilisable ou de la réutilisation inappropriée d'une réponse stockée, plutôt que d'imposer aux caches de toujours stocker et réutiliser des réponses particulières.
Le composant de requête (Query Component) d'une cible de requête (Section 5.3 de [RFC7230]) peut contenir des informations sur la requête spécifiques à un utilisateur, une cohorte d'utilisateurs ou l'état actuel de l'utilisateur. En général, il n'est pas sûr pour un cache de réutiliser une réponse à une requête avec un composant de requête pour satisfaire cette même requête d'un autre utilisateur, car les utilisateurs peuvent avoir des valeurs de requête différentes dans leurs requêtes même si les portions de chemin sont identiques. Un destinataire de cache recevant une réponse réussie avec un composant de requête dans la cible de requête NE DEVRAIT PAS (SHOULD NOT) réutiliser cette réponse pour une requête avec un composant de requête différent, à moins que la réponse ne l'autorise explicitement avec des directives Cache-Control (Section 5.2).
Un cache peut stocker et réutiliser une réponse à une requête avec un composant de requête si la réponse est explicitement autorisée par des directives Cache-Control ou si la réponse contient un validateur (Validator) (Section 2.3 de [RFC7232]) et que le cache suit les exigences de validation. Lorsque cela se produit, un cache PEUT (MAY) utiliser cette réponse pour satisfaire une requête différente, sous réserve de la contrainte que la clé de cache corresponde (Section 4.1), que toutes les exigences de fraîcheur applicables soient satisfaites (Section 4.2) et que toutes les exigences de cache applicables imposées par la requête et la réponse stockée soient satisfaites.
Divers mécanismes existent par lesquels un cache peut apprendre la validité actuelle d'une réponse mise en cache. Une réponse mise en cache est « fraîche » (Fresh) si son âge n'a pas encore dépassé sa durée de vie de fraîcheur (Freshness Lifetime). Inversement, une réponse mise en cache est « périmée » (Stale) si elle a été dans le cache suffisamment longtemps pour atteindre ou dépasser sa durée de vie de fraîcheur.
Une réponse fraîche peut être utilisée pour satisfaire des requêtes ultérieures sans contacter le serveur d'origine, améliorant ainsi l'efficacité. Le protocole inclut des mécanismes permettant à un serveur d'origine d'attribuer une durée de vie de fraîcheur explicite, le calcul d'une durée de vie de fraîcheur heuristique lorsqu'une durée explicite n'est pas définie, et un mécanisme de validation d'une réponse mise en cache pour prolonger sa durée de vie de fraîcheur après qu'elle soit devenue périmée.
Le mécanisme principal pour attribuer la fraîcheur est qu'un serveur d'origine envoie un temps d'expiration explicite via 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 un temps d'expiration explicite suffisant pour satisfaire toutes les utilisations attendues de la réponse. Une durée de vie libérale peut être donnée pour permettre une réutilisation fréquente par les caches ; une durée de vie conservatrice peut être donnée si le contenu est connu pour varier régulièrement.
Lorsqu'un temps d'expiration explicite n'est pas présent, un cache PEUT (MAY) calculer un temps d'expiration heuristique. Un cache NE DOIT PAS (MUST NOT) utiliser des temps d'expiration heuristiques pour les réponses avec des codes d'état dont la mise en cache n'est pas définie par cette spécification, tels que les redirections autres que 300, 301 ou 308 (voir Section 6 de [RFC7231]), ou lorsque le code d'état indique une erreur (c'est-à-dire que le code d'état est supérieur ou égal à 400).
Lorsqu'une réponse stockée est périmée, un cache utilise généralement la validation (requêtes conditionnelles telles que définies dans [RFC7232]) pour mettre à jour la réponse stockée et éviter de transférer les données de représentation inutilement. Une réponse périmée peut toujours être utilisée, sans validation, si l'opération déconnectée est autorisée par la configuration du cache ou si les directives de requête dans Cache-Control le permettent (Section 5.2).