5. Field Definitions (Définitions des champs)

Cette section définit la syntaxe et la sémantique des champs HTTP liés à la mise en cache.

5.1 Age

Le champ d'en-tête de réponse "Age" transmet l'estimation de l'expéditeur du temps écoulé depuis que la réponse a été générée ou validée avec succès au serveur d'origine. La valeur Age est calculée comme spécifié dans la section 4.2.3.

Age = delta-seconds

La valeur du champ Age est un entier non négatif, représentant le temps en secondes (voir la section 1.2.2).

Bien qu'il soit défini comme un champ d'en-tête singleton, un cache qui rencontre un message avec une valeur de champ Age basée sur une liste devrait (SHOULD) utiliser le premier membre de la valeur du champ, en supprimant les membres suivants.

Si la valeur du champ (après avoir supprimé d'autres membres, comme ci-dessus) est invalide (par exemple, elle contient autre chose qu'un entier non négatif), un cache devrait (SHOULD) ignorer le champ.

La présence d'un champ d'en-tête Age implique que la réponse n'a pas été générée ou validée par le serveur d'origine pour cette requête. Cependant, l'absence d'un champ d'en-tête Age n'implique pas que le serveur d'origine a été contacté.

5.2 Cache-Control

Le champ d'en-tête "Cache-Control" est utilisé pour lister les directives pour les caches le long de la chaîne requête/réponse. Les directives de cache sont unidirectionnelles en ce sens que la présence d'une directive dans une requête n'implique pas que la même directive soit présente ou copiée dans la réponse.

Voir la section 5.2.3 pour des informations sur la façon dont les directives Cache-Control définies ailleurs sont gérées.

Un proxy, qu'il implémente ou non un cache, doit (MUST) transmettre les directives de cache dans les messages transférés, quelle que soit leur signification pour cette application, car les directives peuvent s'appliquer à tous les destinataires le long de la chaîne requête/réponse. Il n'est pas possible de cibler une directive vers un cache spécifique.

Les directives de cache sont identifiées par un jeton (à comparer sans distinction de casse), et ont un argument optionnel, qui peut utiliser à la fois la syntaxe de jeton et de chaîne entre guillemets. Pour les directives définies ci-dessous où un argument est défini, les destinataires devraient (SHOULD) accepter les deux formes, même si une forme spécifique est requise pour la génération.

Cache-Control   = #cache-directive

cache-directive = token [ "=" ( token / quoted-string ) ]

Pour les directives de cache définies ci-dessous, aucun argument n'est défini (ni autorisé) sauf indication contraire.

5.2.1 Request Directives (Directives de requête)

Cette section définit les directives de requête de cache. Elles sont consultatives ; les caches peuvent (MAY) les implémenter, mais ne sont pas tenus de le faire.

5.2.1.1 max-age

Syntaxe d'argument :

delta-seconds (voir la section 1.2.2)

La directive de requête max-age indique que le client préfère une réponse dont l'âge est inférieur ou égal au nombre de secondes spécifié. Sauf si la directive de requête max-stale est également présente, le client ne souhaite pas recevoir une réponse périmée.

Cette directive utilise la forme jeton de la syntaxe d'argument : par exemple, 'max-age=5' et non 'max-age="5"'. Un expéditeur ne doit pas (MUST NOT) générer la forme chaîne entre guillemets.

5.2.1.2 max-stale

Syntaxe d'argument :

delta-seconds (voir la section 1.2.2)

La directive de requête max-stale indique que le client acceptera une réponse qui a dépassé sa durée de vie de fraîcheur. Si une valeur est présente, le client est prêt à accepter une réponse qui a dépassé sa durée de vie de fraîcheur de pas plus que le nombre de secondes spécifié. Si aucune valeur n'est attribuée à max-stale, le client acceptera une réponse périmée de tout âge.

Cette directive utilise la forme jeton de la syntaxe d'argument : par exemple, 'max-stale=10' et non 'max-stale="10"'. Un expéditeur ne doit pas (MUST NOT) générer la forme chaîne entre guillemets.

5.2.1.3 min-fresh

Syntaxe d'argument :

delta-seconds (voir la section 1.2.2)

La directive de requête min-fresh indique que le client préfère une réponse dont la durée de vie de fraîcheur n'est pas inférieure à son âge actuel plus le nombre de secondes spécifié. C'est-à-dire que le client souhaite une réponse qui restera fraîche pendant au moins le nombre de secondes spécifié.

Cette directive utilise la forme jeton de la syntaxe d'argument : par exemple, 'min-fresh=20' et non 'min-fresh="20"'. Un expéditeur ne doit pas (MUST NOT) générer la forme chaîne entre guillemets.

5.2.1.4 no-cache

La directive de requête no-cache indique que le client préfère que les réponses stockées ne soient pas utilisées pour satisfaire la requête sans validation réussie au serveur d'origine.

5.2.1.5 no-store

La directive de requête no-store indique qu'un cache ne doit pas (MUST NOT) stocker une partie de cette requête ou de toute réponse à celle-ci. Cette directive s'applique aux caches privés et partagés. "MUST NOT store" dans ce contexte signifie que le cache ne doit pas (MUST NOT) stocker intentionnellement l'information dans un stockage non volatil, et doit (MUST) faire un effort de bonne foi pour supprimer l'information du stockage volatil aussi rapidement que possible après l'avoir transférée.

Cette directive n'est pas un mécanisme fiable ou suffisant pour garantir la confidentialité. En particulier, les caches malveillants ou compromis peuvent ne pas reconnaître ou obéir à cette directive, et les réseaux de communication peuvent être vulnérables à l'écoute clandestine.

Notez que si une requête contenant cette directive est satisfaite à partir d'un cache, la directive de requête no-store ne s'applique pas à la réponse déjà stockée.

5.2.1.6 no-transform

La directive de requête no-transform indique que le client demande à un intermédiaire d'éviter de transformer le contenu, tel que défini par la section 7.7 de [HTTP].

5.2.1.7 only-if-cached

La directive de requête only-if-cached indique que le client souhaite uniquement obtenir une réponse stockée. Un cache qui honore cette directive de requête devrait (SHOULD) répondre avec soit une réponse stockée qui est cohérente avec les autres contraintes de la requête, soit un code d'état 504 (Gateway Timeout) lors de sa réception.

5.2.2 Response Directives (Directives de réponse)

Cette section définit les directives de réponse de cache. Les caches doivent (MUST) obéir aux directives Cache-Control définies dans cette section.

5.2.2.1 max-age

Syntaxe d'argument :

delta-seconds (voir la section 1.2.2)

La directive de réponse max-age indique que la réponse doit être considérée comme périmée après que son âge soit supérieur au nombre de secondes spécifié.

Cette directive utilise la forme jeton de la syntaxe d'argument : par exemple, 'max-age=5' et non 'max-age="5"'. Un expéditeur ne doit pas (MUST NOT) générer la forme chaîne entre guillemets.

5.2.2.2 must-revalidate

La directive de réponse must-revalidate indique qu'une fois que la réponse est devenue périmée, un cache ne doit pas (MUST NOT) réutiliser cette réponse pour satisfaire une autre requête jusqu'à ce qu'elle ait été validée avec succès par le serveur d'origine, tel que défini dans la section 4.3.

La directive must-revalidate est nécessaire pour prendre en charge le fonctionnement fiable de certaines fonctionnalités de protocole. En toutes circonstances, un cache ne doit pas (MUST NOT) ignorer la directive must-revalidate ; en particulier, si un cache est déconnecté, le cache doit (MUST) générer une réponse d'erreur plutôt que de réutiliser la réponse périmée. Le code d'état généré devrait (SHOULD) être 504 (Gateway Timeout) sauf si un autre code d'état d'erreur est plus applicable.

Les serveurs devraient (SHOULD) uniquement utiliser la directive must-revalidate lorsque l'échec de la revalidation d'une requête pourrait entraîner un fonctionnement incorrect (tel qu'une transaction financière exécutée silencieusement).

La directive must-revalidate permet également à un cache partagé de réutiliser une réponse à une requête contenant un champ d'en-tête Authorization (voir la section 11.6.2 de [HTTP]), sous réserve de l'exigence ci-dessus concernant la revalidation (section 3.5).

5.2.2.3 must-understand

La directive de réponse must-understand limite la mise en cache de la réponse aux caches qui comprennent et se conforment aux exigences du code d'état de cette réponse.

Une réponse qui contient une directive must-understand devrait (SHOULD) également contenir une directive no-store. Lorsqu'un cache qui implémente la directive must-understand reçoit une réponse qui la contient, le cache devrait (SHOULD) ignorer la directive no-store s'il comprend et implémente les exigences de mise en cache du code d'état.

5.2.2.4 no-cache

Syntaxe d'argument :

#field-name

La directive de réponse no-cache, sous sa forme non qualifiée (sans argument), indique que la réponse ne doit pas (MUST NOT) être utilisée pour satisfaire toute autre requête sans la transmettre pour validation et recevoir une réponse réussie ; voir la section 4.3.

Cela permet à un serveur d'origine d'empêcher un cache d'utiliser la réponse pour satisfaire une requête sans le contacter, même par des caches qui ont été configurés pour envoyer des réponses périmées.

La forme qualifiée de la directive de réponse no-cache, avec un argument qui liste un ou plusieurs noms de champs, indique qu'un cache peut (MAY) utiliser la réponse pour satisfaire une requête ultérieure, sous réserve de toute autre restriction de mise en cache, si les champs d'en-tête listés sont exclus de la réponse ultérieure ou si la réponse ultérieure a été revalidée avec succès avec le serveur d'origine (en mettant à jour ou en supprimant ces champs). Cela permet à un serveur d'origine d'empêcher la réutilisation de certains champs d'en-tête dans une réponse, tout en permettant la mise en cache du reste de la réponse.

Les noms de champs donnés ne sont pas limités à l'ensemble des champs d'en-tête définis par cette spécification. Les noms de champs sont insensibles à la casse.

Cette directive utilise la forme chaîne entre guillemets de la syntaxe d'argument. Un expéditeur ne devrait pas (SHOULD NOT) générer la forme jeton (même si les guillemets ne semblent pas nécessaires pour les listes à une seule entrée).

Note : La forme qualifiée de la directive est souvent gérée par les caches comme si une directive no-cache non qualifiée avait été reçue ; c'est-à-dire que le traitement spécial de la forme qualifiée n'est pas largement implémenté.

5.2.2.5 no-store

La directive de réponse no-store indique qu'un cache ne doit pas (MUST NOT) stocker une partie de la requête ou de la réponse immédiates, et ne doit pas (MUST NOT) utiliser la réponse pour satisfaire toute autre requête.

Cette directive s'applique aux caches privés et partagés. "MUST NOT store" dans ce contexte signifie que le cache ne doit pas (MUST NOT) stocker intentionnellement l'information dans un stockage non volatil, et doit (MUST) faire un effort de bonne foi pour supprimer l'information du stockage volatil aussi rapidement que possible après l'avoir transférée.

Cette directive n'est pas un mécanisme fiable ou suffisant pour garantir la confidentialité. En particulier, les caches malveillants ou compromis peuvent ne pas reconnaître ou obéir à cette directive, et les réseaux de communication peuvent être vulnérables à l'écoute clandestine.

Notez que la directive de cache must-understand remplace no-store dans certaines circonstances ; voir la section 5.2.2.3.

5.2.2.6 no-transform

La directive de réponse no-transform indique qu'un intermédiaire (qu'il implémente ou non un cache) ne doit pas (MUST NOT) transformer le contenu, tel que défini par la section 7.7 de [HTTP].

5.2.2.7 private

Syntaxe d'argument :

#field-name

La directive de réponse private non qualifiée indique qu'un cache partagé ne doit pas (MUST NOT) stocker la réponse (c'est-à-dire que la réponse est destinée à un seul utilisateur). Elle indique également qu'un cache privé peut (MAY) stocker la réponse, sous réserve des contraintes définies dans la section 3, même si la réponse ne serait pas autrement heuristiquement cachable par un cache privé.

Si une directive de réponse private qualifiée est présente (avec un argument qui liste un ou plusieurs noms de champs), alors seuls les champs d'en-tête listés sont limités à un seul utilisateur : un cache partagé ne doit pas (MUST NOT) stocker les champs d'en-tête listés s'ils sont présents dans la réponse d'origine, mais peut (MAY) stocker le reste du message de réponse sans ces champs d'en-tête, sous réserve des contraintes définies dans la section 3.

Les noms de champs donnés ne sont pas limités à l'ensemble des champs d'en-tête définis par cette spécification. Les noms de champs sont insensibles à la casse.

Cette directive utilise la forme chaîne entre guillemets de la syntaxe d'argument. Un expéditeur ne devrait pas (SHOULD NOT) générer la forme jeton (même si les guillemets ne semblent pas nécessaires pour les listes à une seule entrée).

Note : Cette utilisation du mot "private" contrôle uniquement où la réponse peut être stockée ; elle ne peut pas garantir la confidentialité du contenu du message. De plus, la forme qualifiée de la directive est souvent gérée par les caches comme si une directive private non qualifiée avait été reçue ; c'est-à-dire que le traitement spécial de la forme qualifiée n'est pas largement implémenté.

5.2.2.8 proxy-revalidate

La directive de réponse proxy-revalidate indique qu'une fois que la réponse est devenue périmée, un cache partagé ne doit pas (MUST NOT) réutiliser cette réponse pour satisfaire une autre requête jusqu'à ce qu'elle ait été validée avec succès par le serveur d'origine, tel que défini dans la section 4.3. Ceci est analogue à must-revalidate (section 5.2.2.2), sauf que proxy-revalidate ne s'applique pas aux caches privés.

Notez que proxy-revalidate seul n'implique pas qu'une réponse soit cachable. Par exemple, elle pourrait être combinée avec la directive public (section 5.2.2.9) pour permettre la mise en cache d'une réponse tout en exigeant uniquement que les caches partagés revalidatent lorsqu'elle est périmée.

5.2.2.9 public

La directive de réponse public indique qu'un cache peut (MAY) stocker la réponse même si elle serait autrement interdite, sous réserve des contraintes définies dans la section 3. En d'autres termes, public marque explicitement la réponse comme cachable. Par exemple, public permet à un cache partagé de réutiliser une réponse à une requête contenant un champ d'en-tête Authorization (section 3.5).

Notez qu'il n'est pas nécessaire d'ajouter la directive public à une réponse qui est déjà cachable selon la section 3.

Si une réponse avec une directive public n'a pas d'informations de fraîcheur explicites, elle est heuristiquement cachable (section 4.2.2).

5.2.2.10 s-maxage

Syntaxe d'argument :

delta-seconds (voir la section 1.2.2)

La directive de réponse s-maxage indique que, pour un cache partagé, l'âge maximum spécifié par cette directive remplace l'âge maximum spécifié par la directive max-age ou le champ d'en-tête Expires.

La directive s-maxage incorpore la sémantique de la directive de réponse proxy-revalidate (section 5.2.2.8) pour les caches partagés. Un cache partagé ne doit pas (MUST NOT) réutiliser une réponse périmée avec s-maxage pour satisfaire une autre requête jusqu'à ce qu'elle ait été validée avec succès par le serveur d'origine, tel que défini dans la section 4.3. Cette directive permet également à un cache partagé de réutiliser une réponse à une requête contenant un champ d'en-tête Authorization, sous réserve des exigences ci-dessus concernant l'âge maximum et la revalidation (section 3.5).

Cette directive utilise la forme jeton de la syntaxe d'argument : par exemple, 's-maxage=10' et non 's-maxage="10"'. Un expéditeur ne doit pas (MUST NOT) générer la forme chaîne entre guillemets.

5.2.3 Extension Directives (Directives d'extension)

Le champ d'en-tête Cache-Control peut être étendu par l'utilisation d'une ou plusieurs directives de cache d'extension. Un cache doit (MUST) ignorer les directives de cache non reconnues.

Les extensions informationnelles (celles qui ne nécessitent pas de changement de comportement du cache) peuvent être ajoutées sans changer la sémantique d'autres directives.

Les extensions comportementales sont conçues pour fonctionner en agissant comme des modificateurs de la base existante de directives de cache. La nouvelle directive et l'ancienne directive sont toutes deux fournies, de sorte que les applications qui ne comprennent pas la nouvelle directive utiliseront par défaut le comportement spécifié par l'ancienne directive, et celles qui comprennent la nouvelle directive la reconnaîtront comme modifiant les exigences associées à l'ancienne directive. De cette façon, des extensions aux directives de cache existantes peuvent être apportées sans casser les caches déployés.

Par exemple, considérons une hypothétique nouvelle directive de réponse appelée "community" qui agit comme un modificateur de la directive private : en plus des caches privés, tout cache qui est partagé uniquement par les membres d'une communauté nommée est autorisé à mettre en cache la réponse. Un serveur d'origine souhaitant permettre à la communauté UCI d'utiliser une réponse autrement privée dans leurs caches partagés pourrait le faire en incluant :

Cache-Control: private, community="UCI"

Les caches qui reconnaissent une telle directive de cache community pourraient élargir leur comportement conformément à cette extension. Les caches qui ne reconnaissent pas la directive de cache community l'ignoreraient et adhéreraient à la directive private.

Les nouvelles directives d'extension devraient considérer la définition de :

• Ce que cela signifie pour la directive d'être spécifiée plusieurs fois,

• Lorsque l'argument de la directive est présent, ce que cela signifie lorsque l'argument est absent,

• Lorsque l'argument de la directive est requis, ce que cela signifie lorsque l'argument est manquant, et

• Si la directive est spécifique aux requêtes, spécifique aux réponses, ou capable d'être utilisée dans les deux.

5.2.4 Cache Directive Registry (Registre des directives de cache)

Le "Registre des directives de cache du protocole de transfert hypertexte (HTTP) (Hypertext Transfer Protocol (HTTP) Cache Directive Registry)" définit l'espace de noms pour les directives de cache. Il a été créé et est maintenant maintenu à https://www.iana.org/assignments/http-cache-directives.

Une inscription doit (MUST) inclure les champs suivants :

• Nom de la directive de cache

• Pointeur vers le texte de spécification

Les valeurs à ajouter à cet espace de noms nécessitent une revue IETF (voir la section 4.8 de [RFC8126]).

5.3 Expires

Le champ d'en-tête de réponse "Expires" donne la date/heure après laquelle la réponse est considérée comme périmée. Voir la section 4.2 pour plus de discussion sur le modèle de fraîcheur.

La présence d'un champ d'en-tête Expires n'implique pas que la ressource d'origine changera ou cessera d'exister à, avant ou après ce moment.

La valeur du champ Expires est un horodatage HTTP-date, tel que défini dans la section 5.6.7 de [HTTP]. Pour les exigences d'analyse spécifiques au cache, voir également la section 4.2.

Expires = HTTP-date

Par exemple :

Expires: Thu, 01 Dec 1994 16:00:00 GMT

Un destinataire de cache doit (MUST) interpréter les formats de date invalides, en particulier la valeur "0", comme représentant un moment dans le passé (c'est-à-dire "déjà expiré").

Si une réponse inclut un champ d'en-tête Cache-Control avec la directive max-age (section 5.2.2.1), un destinataire doit (MUST) ignorer le champ d'en-tête Expires. De même, si une réponse inclut la directive s-maxage (section 5.2.2.10), un destinataire de cache partagé doit (MUST) ignorer le champ d'en-tête Expires. Dans l'un ou l'autre de ces cas, la valeur dans Expires est uniquement destinée aux destinataires qui n'ont pas encore implémenté le champ d'en-tête Cache-Control.

Un serveur d'origine sans horloge (voir la section 5.6.7 de [HTTP]) ne doit pas (MUST NOT) générer un champ d'en-tête Expires à moins que sa valeur ne représente un moment fixe dans le passé (toujours expiré) ou que sa valeur ait été associée à la ressource par un système avec une horloge.

Historiquement, HTTP exigeait que la valeur du champ Expires ne soit pas supérieure à un an dans le futur. Bien que des durées de vie de fraîcheur plus longues ne soient plus interdites, des valeurs extrêmement grandes ont été démontrées pour causer des problèmes (par exemple, débordement d'horloge dû à l'utilisation d'entiers 32 bits pour les valeurs de temps), et de nombreux caches évacueront une réponse beaucoup plus tôt.

5.4 Pragma

Le champ d'en-tête de requête "Pragma" a été défini pour les caches HTTP/1.0, afin que les clients puissent spécifier une requête "no-cache" (puisque Cache-Control n'a été défini qu'avec HTTP/1.1).

Cependant, le support de Cache-Control est maintenant répandu. En conséquence, cette spécification déprécie Pragma.

Note : Parce que la signification de "Pragma: no-cache" dans les réponses n'a jamais été spécifiée, elle ne fournit pas un remplacement fiable pour "Cache-Control: no-cache" dans les réponses.

5.5 Warning

Le champ d'en-tête "Warning" était utilisé pour transporter des informations supplémentaires sur l'état ou la transformation d'un message qui pourraient ne pas être reflétées dans le code d'état. Cette spécification l'obsolète, car il n'est pas largement généré ou affiché aux utilisateurs. Les informations qu'il transportait peuvent être recueillies en examinant d'autres champs d'en-tête, tels que Age.