2. Le champ d'en-tête de réponse HTTP Cache-Status

Le champ d'en-tête de réponse HTTP Cache-Status indique comment les caches ont traité cette réponse et sa requête correspondante. La syntaxe de ce champ d'en-tête est conforme à [STRUCTURED-FIELDS].

Sa valeur est une List. Chaque membre de la List représente un cache qui a traité la requête. Le premier membre représente le cache le plus proche du serveur d'origine, et le dernier membre représente le cache le plus proche de l'utilisateur (incluant éventuellement le cache de l'agent utilisateur lui-même s'il ajoute une valeur).

Les caches déterminent quand il est approprié d'ajouter le champ d'en-tête Cache-Status à une réponse. Certains peuvent l'ajouter à toutes les réponses, tandis que d'autres ne le font que lorsqu'ils sont spécifiquement configurés pour le faire, ou lorsque la requête contient un champ d'en-tête qui active un mode de débogage. Voir la section 6 pour les considérations de sécurité connexes.

Un intermédiaire NE DEVRAIT PAS (SHOULD NOT) ajouter un membre Cache-Status aux réponses qu'il génère localement, même si cet intermédiaire contient un cache, à moins que la réponse générée ne soit basée sur une réponse stockée (par exemple, 304 (Not Modified) et 206 (Partial Content) sont tous deux basés sur une réponse stockée). Par exemple, un proxy générant une réponse 400 en raison d'une requête mal formée n'ajoutera pas de valeur Cache-Status, car cette réponse a été générée par le proxy, et non par le serveur d'origine.

Lors de l'ajout d'une valeur au champ d'en-tête Cache-Status, les caches DEVRAIENT (SHOULD) préserver la valeur de champ existante, pour permettre le débogage de toute la chaîne de caches traitant la requête.

Chaque membre de la List identifie le cache qui l'a inséré, et cet identifiant DOIT (MUST) être une String ou un Token. Selon le déploiement, il peut s'agir d'un nom de produit ou de service (par exemple, "ExampleCache" ou "Example CDN"), d'un nom d'hôte ("cache-3.example.com"), d'une adresse IP ou d'une chaîne générée.

Chaque membre de la liste peut avoir des paramètres qui décrivent le traitement de la requête par ce cache. Bien que ces paramètres soient OPTIONNELS (OPTIONAL), les caches sont encouragés à fournir autant d'informations que possible.

Cette spécification définit les paramètres suivants.

2.1. Le paramètre hit

La valeur de "hit" est un Boolean qui, lorsqu'il est vrai, indique que la requête a été satisfaite par le cache ; c'est-à-dire qu'elle n'a pas été transmise et que la réponse a été obtenue du cache.

Une réponse qui a été produite à l'origine par l'origine mais a été modifiée par le cache (par exemple, un code de statut 304 ou 206) est toujours considérée comme un hit, tant qu'elle n'a pas été transmise (par exemple, pour validation).

Une réponse qui était dans le cache mais qui ne pouvait pas être utilisée sans être transmise (par exemple, parce qu'elle était périmée ou partielle) n'est pas considérée comme un hit. Notez qu'une réponse périmée qui est utilisée sans être transmise (par exemple, parce que le serveur d'origine n'est pas disponible) peut être considérée comme un hit.

"hit" et "fwd" sont exclusifs ; un seul d'entre eux devrait apparaître sur chaque membre de la liste.

2.2. Le paramètre fwd

"fwd", lorsqu'il est présent, indique que la requête a été transmise vers l'origine ; sa valeur est un Token qui indique pourquoi.

Les valeurs de paramètre suivantes sont définies pour expliquer pourquoi la requête a été transmise, de la plus spécifique à la moins spécifique :

bypass : Le cache a été configuré pour ne pas traiter cette requête.

method : La sémantique de la méthode de requête nécessite que la requête soit transmise.

uri-miss : Le cache ne contenait aucune réponse correspondant à l'URI de la requête.

vary-miss : Le cache contenait une réponse correspondant à l'URI de la requête, mais il n'a pas pu sélectionner une réponse en fonction des champs d'en-tête de cette requête et des champs d'en-tête Vary stockés.

miss : Le cache ne contenait aucune réponse pouvant être utilisée pour satisfaire cette requête (à utiliser lorsqu'une implémentation ne peut pas distinguer entre uri-miss et vary-miss).

request : Le cache a pu sélectionner une réponse fraîche pour la requête, mais la sémantique de la requête (par exemple, les directives de requête Cache-Control) n'a pas permis son utilisation.

stale : Le cache a pu sélectionner une réponse pour la requête, mais elle était périmée.

partial : Le cache a pu sélectionner une réponse partielle pour la requête, mais elle ne contenait pas toutes les plages demandées (ou la requête demandait la réponse complète).

La raison la plus spécifique connue du cache DEVRAIT (SHOULD) être utilisée, dans la mesure où il est possible de l'implémenter. Voir également [HTTP-CACHING], section 4.

2.3. Le paramètre fwd-status

La valeur de "fwd-status" est un Integer qui indique quel code de statut (voir [HTTP], section 15) le serveur de saut suivant a renvoyé en réponse à la requête transmise. Le paramètre fwd-status n'a de sens que lorsque fwd est présent. Si fwd-status n'est pas présent mais que le paramètre fwd l'est, il prend par défaut le code de statut envoyé dans la réponse.

Ce paramètre est utile pour distinguer les cas où le serveur de saut suivant envoie une réponse 304 (Not Modified) à une requête conditionnelle ou une réponse 206 (Partial Content) en raison d'une requête de plage.

2.4. Le paramètre ttl

La valeur de "ttl" est un Integer qui indique la durée de vie de fraîcheur restante de la réponse (voir [HTTP-CACHING], section 4.2.1) telle que calculée par le cache, en nombre entier de secondes, mesurée aussi près que possible du moment où la section d'en-tête de réponse est envoyée par le cache. Cela inclut la fraîcheur attribuée par le cache par le biais, par exemple, d'heuristiques (voir [HTTP-CACHING], section 4.2.2), de configuration locale ou d'autres facteurs. Il peut être négatif, pour indiquer l'obsolescence.

2.5. Le paramètre stored

La valeur de "stored" est un Boolean qui indique si le cache a stocké la réponse (voir [HTTP-CACHING], section 3) ; une valeur vraie indique qu'il l'a fait. Le paramètre stored n'a de sens que lorsque fwd est présent.

2.6. Le paramètre collapsed

La valeur de "collapsed" est un Boolean qui indique si cette requête a été regroupée avec une ou plusieurs autres requêtes transmises (voir [HTTP-CACHING], section 4). Si vrai, la réponse a été réutilisée avec succès ; sinon, une nouvelle requête a dû être effectuée. S'il n'est pas présent, la requête n'a pas été regroupée avec d'autres. Le paramètre collapsed n'a de sens que lorsque fwd est présent.

2.7. Le paramètre key

La valeur de "key" est une String qui transmet une représentation de la clé de cache (voir [HTTP-CACHING], section 2) utilisée pour la réponse. Notez que cela peut être spécifique à l'implémentation.

2.8. Le paramètre detail

La valeur de "detail" est soit une String, soit un Token qui permet aux implémentations de transmettre des informations supplémentaires non capturées dans d'autres paramètres, telles que des états spécifiques à l'implémentation ou d'autres métriques liées à la mise en cache.

Par exemple :

Cache-Status: ExampleCache; hit; detail=MEMORY

La sémantique d'un paramètre detail est toujours spécifique au cache qui l'a envoyé ; même si un paramètre details d'un autre cache partage la même valeur, il peut ne pas signifier la même chose.

Ce paramètre est intentionnellement limité. Si le développeur ou l'opérateur d'une implémentation a besoin de transmettre des informations supplémentaires de manière interopérable, il est encouragé à enregistrer des paramètres d'extension (voir section 4) ou à définir un autre champ d'en-tête.