5.2.2 Response Cache-Control Directives
Cette section définit les directives de cache qui peuvent être utilisées par un serveur d'origine ou un intermédiaire dans une réponse HTTP.
5.2.2.1. 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) utiliser la réponse pour satisfaire des requêtes ultérieures sans validation réussie sur le serveur d'origine.
La directive must-revalidate est nécessaire pour prendre en charge le fonctionnement fiable de certaines fonctionnalités du protocole. Dans toutes les circonstances, un cache DOIT (MUST) obéir à la directive must-revalidate ; en particulier, si un cache ne peut atteindre le serveur d'origine pour quelque raison que ce soit, il DOIT (MUST) générer une réponse 504 (Gateway Timeout).
La directive must-revalidate devrait (ought to) être utilisée par les serveurs si et seulement si l'échec de validation d'une requête pourrait entraîner un fonctionnement incorrect, tel qu'une transaction financière silencieusement non exécutée.
5.2.2.2. no-cache
Argument : #field-name (optionnel)
La directive de réponse "no-cache" indique que la réponse NE DOIT PAS (MUST NOT) être utilisée pour satisfaire une requête ultérieure sans validation réussie sur le serveur d'origine. 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.
Si la directive de réponse no-cache spécifie un ou plusieurs noms de champs, alors un cache PEUT (MAY) utiliser la réponse pour satisfaire une requête ultérieure, sous réserve de toute autre restriction sur la mise en cache. Cependant, tous les noms de champs spécifiés NE DOIVENT PAS (MUST NOT) être envoyés dans la réponse à une requête ultérieure sans revalidation réussie avec le serveur d'origine. 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.
Remarque : La plupart des caches HTTP/1.0 ne reconnaîtront pas ou n'obéiront pas à cette directive. De plus, les directives de réponse no-cache avec des noms de champs sont souvent traitées par les implémentations comme si une directive no-cache non qualifiée avait été reçue ; c'est-à-dire que le traitement spécial pour la forme qualifiée n'est pas largement implémenté.
5.2.2.3. no-store
La directive de réponse "no-store" indique qu'un cache NE DOIT PAS (MUST NOT) stocker une partie quelconque de la requête immédiate ou de la réponse. Cette directive s'applique aux caches privés et partagés. "NE DOIT PAS stocker" dans ce contexte signifie que le cache NE DOIT PAS (MUST NOT) intentionnellement stocker les informations dans un stockage non volatile, et DOIT (MUST) faire un effort maximal pour supprimer les informations du stockage volatile aussi rapidement que possible après les avoir transmises.
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 aux écoutes clandestines.
5.2.2.4. 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 la charge utile, comme défini dans la Section 5.7.2 de [RFC7230].
5.2.2.5. public
La directive de réponse "public" indique que tout cache PEUT (MAY) stocker la réponse, même si la réponse serait normalement non cacheable ou cacheable uniquement dans un cache privé. (Voir également la Section 3.2, qui discute de l'effet du champ d'en-tête Authorization sur la cacheabilité.)
5.2.2.6. private
Argument : #field-name (optionnel)
La directive de réponse "private" indique que la réponse est destinée à un seul utilisateur et NE DOIT PAS (MUST NOT) être stockée par un cache partagé. Un cache privé PEUT (MAY) stocker la réponse et la réutiliser pour des requêtes ultérieures, même si la réponse serait normalement non cacheable.
Si la directive de réponse private spécifie un ou plusieurs noms de champs, cette exigence est limitée aux valeurs de champs associées aux champs d'en-tête de réponse listés. C'est-à-dire qu'un cache partagé NE DOIT PAS (MUST NOT) stocker les noms de champs spécifiés, alors qu'il PEUT (MAY) stocker le reste du message de réponse.
Remarque : 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 aux écoutes clandestines.
5.2.2.7. proxy-revalidate
La directive de réponse "proxy-revalidate" a la même signification que la directive de réponse must-revalidate, sauf qu'elle ne s'applique pas aux caches privés.
5.2.2.8. max-age
Argument : delta-seconds
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 émetteur NE DEVRAIT PAS (SHOULD NOT) générer la forme de chaîne entre guillemets.
5.2.2.9. s-maxage
Argument : delta-seconds
La directive de réponse "s-maxage" indique que, dans les caches partagés, l'âge maximum spécifié par cette directive remplace l'âge maximum spécifié soit par la directive max-age soit par le champ d'en-tête Expires. La directive s-maxage implique également la sémantique de la directive de réponse proxy-revalidate.
Cette directive utilise la forme jeton de la syntaxe d'argument : par exemple, 's-maxage=10' et non 's-maxage="10"'. Un émetteur NE DEVRAIT PAS (SHOULD NOT) générer la forme de chaîne entre guillemets.