max-age
Le max-age=N La directive de réponse indique que la réponse reste fraîche jusqu'à N quelques secondes après la génération de la réponse.
Cache-Control: max-age=604800
Indique que les caches peuvent stocker cette réponse et la réutiliser pour les demandes ultérieures pendant qu'elle est fraîche.
Noter que max-age n'est pas le temps écoulé depuis que la réponse a été reçue; C'est le temps écoulé depuis que la réponse a été générée sur le serveur d'origine. Donc, si les autres caches – sur l'itinéraire du réseau emprunté par la réponse – stockez la réponse pendant 100 secondes (indiquée Age Champ d'en-tête de réponse), le cache du navigateur déduirait 100 secondes de sa durée de vie de la fraîcheur.
Si le max-age La valeur est négative (par exemple, -1) ou n'est pas un entier (par exemple, 3599.99), alors le comportement de mise en cache n'est pas spécifié. Les caches sont encouragées à traiter la valeur comme si elle était 0 (Ceci est noté dans la section de la durée de vie de la fraîcheur calculative de la spécification HTTP).
Cache-Control: max-age=604800
Age: 100
s-maxage
Le s-maxage La directive de réponse indique combien de temps la réponse reste fraîche dans un cache partagé. Le s-maxage La directive est ignorée par les caches privées et remplace la valeur spécifiée par le max-age directive ou le Expires En-tête pour les caches partagées, s'ils sont présents.
Cache-Control: s-maxage=604800
no-cache
Le no-cache La directive de réponse indique que la réponse peut être stockée dans les caches, mais la réponse doit être validée avec le serveur d'origine avant chaque réutilisation, même lorsque le cache est déconnecté du serveur d'origine.
Si vous voulez que les caches vérifient toujours les mises à jour de contenu tout en réutilisant le contenu stocké, no-cache est la directive à utiliser. Il le fait en exigeant que les caches revalissent chaque demande avec le serveur d'origine.
Noter que no-cache Cela ne signifie pas « ne cache pas ». no-cache Permet aux caches de stocker une réponse mais les oblige à le révalider avant la réutilisation. Si le sentiment de « ne cache pas » que vous voulez est en fait « ne stockez pas », alors no-store est la directive à utiliser.
must-revalidate
Le must-revalidate La directive de réponse indique que la réponse peut être stockée dans les caches et peut être réutilisée en fraîcheur. Si la réponse devient périmée, elle doit être validée avec le serveur d'origine avant la réutilisation.
Typiquement, must-revalidate est utilisé avec max-age.
Cache-Control: max-age=604800, must-revalidate
HTTP permet aux caches de réutiliser les réponses périmées lorsqu'elles sont déconnectées du serveur d'origine. must-revalidate est un moyen d'éviter que cela se produise – soit la réponse stockée est révalidée avec le serveur d'origine, soit une réponse 504 (délai d'expiration de la passerelle) est générée.
proxy-revalidate
Le proxy-revalidate La directive de réponse est l'équivalent de must-revalidatemais spécifiquement pour les caches partagés uniquement.
no-store
Le no-store La directive de réponse indique que les caches de toute nature (privées ou partagées) ne doivent pas stocker cette réponse.
private
Le private La directive de réponse indique que la réponse ne peut être stockée que dans un cache privé (par exemple, les caches locales dans les navigateurs).
Vous devriez ajouter le private Directive pour le contenu personnalisé par l'utilisateur, en particulier pour les réponses reçues après la connexion et pour les sessions gérées via des cookies.
Si vous oubliez d'ajouter private À une réponse avec du contenu personnalisé, cette réponse peut être stockée dans un cache partagé et finir par être réutilisée pour plusieurs utilisateurs, ce qui peut entraîner la fuite d'informations personnelles.
public
Le public La directive de réponse indique que la réponse peut être stockée dans un cache partagé. Réponses des demandes avec Authorization Les champs d'en-tête ne doivent pas être stockés dans un cache partagé; Cependant, le public La directive entraînera le stockage de ces réponses dans un cache partagé.
En général, lorsque les pages sont sous Auth Basic ou Digest Auth, le navigateur envoie des demandes avec le Authorization en-tête. Cela signifie que la réponse est contrôlée par l'accès pour les utilisateurs restreints (qui ont des comptes), et il n'est fondamentalement pas caché, même s'il a max-age.
Vous pouvez utiliser le public directive pour déverrouiller cette restriction.
Cache-Control: public, max-age=604800
Noter que s-maxage ou must-revalidate Déverrouillez également cette restriction.
Si une demande n'a pas de Authorization en-tête, ou vous utilisez déjà s-maxage ou must-revalidate Dans la réponse, alors vous n'avez pas besoin d'utiliser public.
must-understand
Le must-understand La directive de réponse indique qu'un cache ne doit stocker la réponse que s'il comprend les exigences de mise en cache en fonction du code d'état.
must-understand devrait être couplé à no-store pour le comportement de secours.
Cache-Control: must-understand, no-store
Si un cache ne prend pas en charge must-understandil sera ignoré. Si no-store est également présent, la réponse n'est pas stockée.
Si un cache prend en charge must-understandil stocke la réponse avec une compréhension des exigences du cache en fonction de son code d'état.
no-transform
Certains intermédiaires transforment le contenu pour diverses raisons. Par exemple, certains convertissent des images pour réduire la taille du transfert. Dans certains cas, cela n'est pas souhaitable pour le fournisseur de contenu.
no-transform indique que tout intermédiaire (qu'il ait ou non un cache) ne doit pas transformer le contenu de la réponse.
immutable
Le immutable La directive de réponse indique que la réponse ne sera pas mise à jour pendant qu'elle est fraîche.
Cache-Control: public, max-age=604800, immutable
Une meilleure pratique moderne pour les ressources statiques consiste à inclure la version / les hachages dans leurs URL, tout en ne modifiant jamais les ressources – mais au lieu de cela, si nécessaire, mise à jour Les ressources avec des versions plus récentes qui ont de nouvelles version / hachages de version, afin que leurs URL soient différentes. C'est ce qu'on appelle le cache-cache modèle.
Lorsqu'un utilisateur recharge le navigateur, le navigateur enverra des demandes conditionnelles pour valider le serveur d'origine. Mais il n'est pas nécessaire de revalider ces types de ressources statiques même lorsqu'un utilisateur recharge le navigateur, car ils ne sont jamais modifiés.
immutable Indique un cache que la réponse est immuable alors qu'elle est fraîche et évite les types de demandes conditionnelles inutiles au serveur.
Lorsque vous utilisez un modèle de cache pour les ressources et que vous les appliquez à un long max-agevous pouvez également ajouter immutable pour éviter la revalidation.
stale-while-revalidate
Le stale-while-revalidate La directive de réponse indique que le cache pourrait réutiliser une réponse obsolète alors qu'elle le revient à un cache.
Cache-Control: max-age=604800, stale-while-revalidate=86400
Dans l'exemple ci-dessus, la réponse est fraîche pendant 7 jours (604800). Après 7 jours, il devient périmé, mais le cache est autorisé à le réutiliser pour toutes les demandes qui sont faites le lendemain (86400), à condition qu'ils revalient la réponse en arrière-plan.
La revalidation fera à nouveau le cache, il semble donc aux clients qu'il a toujours été frais pendant cette période – cachant efficacement la pénalité de latence de la revalidation de leur part.
Si aucune demande ne s'est produite au cours de cette période, le cache est devenu périmé et la prochaine demande reviendra normalement.
stale-if-error
Le stale-if-error La directive de réponse indique que le cache peut réutiliser une réponse périmée lorsqu'un serveur en amont génère une erreur ou lorsque l'erreur est générée localement. Ici, une erreur est considérée comme une réponse avec un code d'état de 500, 502, 503 ou 504.
Cache-Control: max-age=604800, stale-if-error=86400
Dans l'exemple ci-dessus, la réponse est fraîche pendant 7 jours (604800). Ensuite, il devient périmé, mais peut être utilisé pendant un jour supplémentaire (86400) lorsqu'une erreur est rencontrée.
Une fois que la période d'erreur sévère sévère, le client recevra toute erreur générée.
