2. Champs d'en-tête Cache-Control Ciblés

Un Champ d'en-tête Cache-Control Ciblé (ci-après "champ ciblé") est un champ d'en-tête de réponse HTTP qui a la même sémantique que le champ d'en-tête de réponse Cache-Control ([HTTP-CACHING], Section 5.2). Cependant, il a un nom de champ distinct qui indique la cible de ses directives de cache.

Par exemple :

CDN-Cache-Control: max-age=60

est un champ ciblé qui s'applique aux CDN, comme défini dans la Section 3.

2.1. Syntaxe

Les champs ciblés sont des Champs Structurés Dictionnaires (Section 3.2 de [STRUCTURED-FIELDS]). Chaque membre du Dictionnaire est une directive de réponse de cache HTTP (Section 5.2.2 de [HTTP-CACHING]) incluant les directives de réponse d'extension (selon la Section 5.2.3 de [HTTP-CACHING]). Notez que bien que les champs ciblés aient souvent la même syntaxe que les champs Cache-Control, les différences de gestion des erreurs signifient que l'utilisation d'un analyseur Cache-Control plutôt qu'un analyseur de Champs Structurés peut introduire des problèmes d'interopérabilité.

Parce que les directives de cache ne sont pas définies en termes de types de données structurées, il est nécessaire de mapper leurs valeurs dans les types appropriés. La Section 5.2 de [HTTP-CACHING] définit les valeurs de directive de cache comme étant soit absentes, une chaîne entre guillemets, ou un jeton.

Cela signifie que les directives de cache qui n'ont pas de valeur seront mappées sur un Booléen (Section 3.3.6 de [STRUCTURED-FIELDS]). Lorsque la valeur est une chaîne entre guillemets, elle sera mappée sur une Chaîne (Section 3.3.3 de [STRUCTURED-FIELDS]), et lorsqu'elle est un jeton, elle sera mappée sur un Jeton (Section 3.3.4 de [STRUCTURED-FIELDS]), un Entier (Section 3.3.1 de [STRUCTURED-FIELDS]), ou un Décimal (Section 3.3.2 de [STRUCTURED-FIELDS]), selon le contenu de la valeur.

Par exemple, la directive max-age (Section 5.2.2.1 de [HTTP-CACHING]) a une valeur entière ; no-store (Section 5.2.2.5 de [HTTP-CACHING]) a toujours une valeur booléenne vraie, et no-cache (Section 5.2.2.4 de [HTTP-CACHING]) a une valeur qui peut être soit booléenne vraie, soit une chaîne contenant une liste délimitée par des virgules de noms de champs.

Les implémentations NE DOIVENT PAS (MUST NOT) générer des valeurs qui violent ces contraintes inférées sur la valeur de la directive de cache. En particulier, les valeurs de chaîne dont le premier caractère n'est pas alphabétique ou "*" DOIVENT (MUST) être générées en tant que Chaînes afin de ne pas être confondues avec d'autres types.

Les implémentations NE DEVRAIENT PAS (SHOULD NOT) consommer des valeurs qui violent ces contraintes inférées. Par exemple, une implémentation consommatrice qui force une max-age avec une valeur décimale en un entier se comporterait différemment des autres implémentations, causant potentiellement des problèmes d'interopérabilité.

Les paramètres reçus sur les directives de cache doivent être ignorés, sauf si une autre gestion est explicitement spécifiée.

Si un champ ciblé dans une réponse donnée est vide, ou si une erreur d'analyse est rencontrée, ce champ DOIT (MUST) être ignoré par le cache (c'est-à-dire qu'il se comporte comme si le champ n'était pas présent, tombant probablement sur d'autres mécanismes de contrôle de cache présents).

2.2. Comportement du cache

Un cache qui implémente cette spécification maintient une liste cible. Une liste cible est une liste ordonnée des noms de champs ciblés qu'il utilise pour la politique de mise en cache, l'ordre reflétant la priorité du plus applicable au moins applicable. La liste cible peut être fixe, configurable par l'utilisateur ou générée par requête, selon l'implémentation.

Par exemple, un cache CDN pourrait prendre en charge à la fois CDN-Cache-Control et un en-tête spécifique à ce CDN, ExampleCDN-Cache-Control, ce dernier remplaçant le premier. Sa liste cible serait :

[ExampleCDN-Cache-Control, CDN-Cache-Control]

Lorsqu'un cache qui implémente cette spécification reçoit une réponse avec un ou plusieurs des noms de champs d'en-tête de sa liste cible, le cache DOIT (MUST) sélectionner le premier (dans l'ordre de la liste cible) champ avec une valeur valide et non vide et utiliser sa valeur pour déterminer la politique de mise en cache pour la réponse, et il DOIT (MUST) ignorer les champs d'en-tête Cache-Control et Expires dans cette réponse, sauf si aucune valeur valide et non vide n'est disponible à partir des champs d'en-tête listés.

Notez que cela se produit sur une base réponse par réponse ; si aucun membre de la liste cible du cache n'est présent, valide et non vide, un cache retombe sur d'autres mécanismes de contrôle de cache comme requis par HTTP [HTTP-CACHING].

Les champs ciblés qui ne sont pas sur la liste cible d'un cache NE DOIVENT PAS (MUST NOT) changer le comportement de ce cache et DOIVENT (MUST) être transmis.

Les caches qui utilisent un champ ciblé DOIVENT (MUST) implémenter la sémantique des directives de cache suivantes :

• max-age
• must-revalidate
• no-store
• no-cache
• private

De plus, ils DEVRAIENT (SHOULD) implémenter d'autres directives de cache (y compris les directives de cache d'extension) qu'ils prennent en charge dans le champ d'en-tête de réponse Cache-Control.

La sémantique et la précédence des directives de cache dans un champ ciblé sont les mêmes que celles dans Cache-Control. En particulier, no-store et no-cache rendent max-age inopérant, et les directives d'extension non reconnues sont ignorées.

2.3. Interaction avec la fraîcheur HTTP

La mise en cache HTTP a un seul modèle de fraîcheur de bout en bout défini dans la Section 4.2 de [HTTP-CACHING]. Lorsque des mécanismes de fraîcheur supplémentaires ne sont disponibles que pour certains caches le long d'un chemin de requête (par exemple, en utilisant des champs ciblés), leurs interactions doivent être soigneusement considérées. En particulier, un cache ciblé pourrait avoir des durées de vie de fraîcheur plus longues disponibles que d'autres caches, l'amenant à servir des réponses qui semblent prématurément (ou même immédiatement) périmées pour ces autres caches, impactant négativement l'efficacité du cache.

Par exemple, une réponse stockée par un cache CDN pourrait être servie avec les en-têtes suivants :

Age: 1800
Cache-Control: max-age=600
CDN-Cache-Control: max-age=3600

Du point de vue du CDN, cette réponse est toujours fraîche après avoir été mise en cache pendant 30 minutes, tandis que du point de vue des autres caches, cette réponse est déjà périmée. Voir [AGE-PENALTY] pour plus de discussion.

Lorsque le cache ciblé a un mécanisme de cohérence fort (par exemple, le serveur d'origine a la capacité d'invalider de manière proactive les réponses mises en cache), il est souvent souhaitable d'atténuer ces effets. Certaines techniques vues dans les déploiements incluent :

• Suppression du champ d'en-tête Age
• Mise à jour de la valeur du champ d'en-tête Date à l'heure actuelle
• Mise à jour de la valeur du champ d'en-tête Expires à l'heure actuelle, plus toute valeur Cache-Control: max-age

Cette spécification ne place aucune exigence spécifique sur les implémentations pour atténuer ces effets, mais les définitions de champs ciblés peuvent le faire.

2.4. Définition des champs ciblés

Un champ ciblé pour une classe particulière de cache peut être défini en demandant l'enregistrement dans le "Registre des Noms de Champs du Protocole de Transfert Hypertexte (HTTP)" (<https://www.iana.org/assignments/http-fields/>).

Les demandes d'enregistrement peuvent utiliser ce document comme document de spécification ; dans ce cas, le champ Commentaires doit clairement définir la classe de caches à laquelle le champ ciblé s'applique. Alternativement, si une autre documentation pour le champ a été créée, elle peut être utilisée comme document de spécification.

Par convention, les champs ciblés ont le suffixe "-Cache-Control", par exemple, "ExampleCDN-Cache-Control". Cependant, ce suffixe NE DOIT PAS (MUST NOT) être utilisé seul pour identifier les champs ciblés ; c'est seulement une convention.