Différence entre no-cache et must-revalidate

Question

Extrait de la RFC 2616

http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.1

no-cache

Si la directive no-cache ne spécifie pas un nom de champ, alors un cache NE DOIT PAS utiliser la réponse pour satisfaire une demande ultérieure sans une sans revalidation réussie auprès du serveur d'origine. Cela permet à un serveur d'origine d'origine d'empêcher la mise en cache même par les caches qui ont été configurés pour renvoyer des réponses périmées aux demandes des clients.

Elle demande donc aux agents de revalider tous réponses.

Comparé à

must-revalidate

Lorsque la directive must-revalidate est présente dans une réponse reçue par un cache, ce dernier NE DOIT PAS utiliser l'entrée après qu'elle soit devenue périmée pour répondre à une demande ultérieure sans la revalider au préalable auprès du le serveur d'origine

Elle demande donc aux agents de revalider rassis réponses.

Notamment en ce qui concerne no-cache Est-ce ainsi que les agents utilisateurs traitent réellement, empiriquement, cette directive ?

Quel est l'intérêt de no-cache s'il y a must-revalidate y max-age ?

Voir ce commentaire :

http://palpapers.plynt.com/issues/2008Jul/cache-control-attributes/

no-cache

Bien que cette directive semble demander au navigateur de ne pas mettre en de ne pas mettre la page en cache, il y a une différence subtile. La directive "no-cache", selon la RFC, indique au navigateur qu'il doit revalider avec le serveur le serveur avant de servir la page à partir du cache. La revalidation est une technique astucieuse qui permet à l'application de conserver la bande passante. Si la Si la page que le navigateur a mise en cache n'a pas été modifiée, le serveur le signale simplement au navigateur et la page est envoyée au serveur. le serveur le signale au navigateur et la page est affichée à partir du cache. Ainsi, le navigateur (en théorie, du moins), stocke la page dans son cache, mais mais ne l'affiche qu'après l'avoir revalidée auprès du serveur. En pratique, IE et Firefox ont commencé à traiter la directive no-cache comme si elle comme si elle demandait au navigateur de ne même pas mettre la page en cache. Nous avons commencé à observer ce comportement il y a environ un an. Nous pensons que ce changement a été changement a été provoqué par l'utilisation répandue (et incorrecte) de cette directive pour pour empêcher la mise en cache.

Quelqu'un a-t-il des informations plus officielles à ce sujet ?

Mise à jour

La directive must-revalidate doit être utilisée par les serveurs si et seulement si l'échec de la validation d'une requête sur la représentation peut entraîner une opération incorrecte, telle qu'une transaction financière non exécutée en silence.

C'est quelque chose que je n'ai jamais pris à cœur jusqu'à maintenant. La RFC dit de ne pas utiliser must-revalidate à la légère. Le fait est qu'avec les services web, vous devez adopter une vision négative et supposer le pire pour vos applications clientes inconnues. Toute ressource périmée a le potentiel de causer un problème.

Autre chose que je viens de considérer, sans Last-Modified ou ETags, le navigateur ne peut que récupérer à nouveau la ressource entière. Cependant, avec ETags, j'ai observé que Chrome semble au moins revalider à chaque demande. Ce qui rend ces deux directives inutiles, ou du moins mal nommées, puisqu'elles ne peuvent pas revalider correctement, à moins que la requête ne contienne également d'autres en-têtes qui provoquent de toute façon une "revalidation systématique".

Je veux juste rendre ce dernier point plus clair. En mettant juste must-revalidate mais sans inclure ni ETag ni Last-Modified, l'agent ne peut que récupérer le contenu puisqu'il n'a rien à envoyer au serveur pour le comparer.

Cependant, mes tests empiriques ont montré que lorsque des données ETag ou des données d'en-tête modifiées sont incluses dans les réponses, les agents revalident toujours de toute façon, indépendamment de la présence de la balise must-revalidate en-tête.

Donc le point de must-revalidate est de forcer un "bypass cache" lorsqu'il devient périmé, ce qui ne peut se produire que lorsque vous avez défini une durée de vie/un âge, donc si must-revalidate est défini sur une réponse sans âge ou autres en-têtes, il devient effectivement équivalent à no-cache car la réponse sera considérée comme immédiatement périmée.

-- Je vais donc enfin marquer la réponse de Gili !

Answer 1

Je crois que must-revalidate signifie :

Une fois que le cache a expiré, refusez de renvoyer les réponses périmées à l'utilisateur. même s'ils disent que les réponses périmées sont acceptables.

Considérant que no-cache implique :

must-revalidate plus le fait que la réponse devient tout de suite périmée.

Si une réponse peut être mise en cache pendant 10 secondes, alors must-revalidate se déclenche après 10 secondes, tandis que no-cache implique must-revalidate après 0 seconde.

Du moins, c'est mon interprétation.

Answer 2

max-age=0, must-revalidate y no-cache ne sont pas exactement identiques. Avec must-revalidate Si le serveur ne répond pas à une demande de revalidation, le navigateur/proxy est censé renvoyer une erreur 504. Avec no-cache Si l'utilisateur n'est pas satisfait, il n'affichera que le contenu en cache, ce qui est probablement préférable pour l'utilisateur (mieux vaut avoir quelque chose de périmé que rien du tout). C'est pourquoi must-revalidate est destiné uniquement aux transactions critiques.

Answer 3

Avec l'interprétation de Jeffrey Fox sur no-cache J'ai testé sous chrome 52.0.2743.116 m, le résultat montre que no-cache a le même comportement que must-revalidate ils le feront tous PAS utilisent le cache local lorsque le serveur est inaccessible, et ils utilisent tous le cache en appuyant sur le bouton Précédent/Prochain du navigateur lorsque le serveur est inaccessible. Comme ci-dessus, je pense que max-age=0, must-revalidate est identique à no-cache du moins dans la mise en œuvre.

Answer 4

Pour ce que ça vaut, la page MDN sur la validation HTTP aborde directement cette question (c'est moi qui souligne) :

Il est souvent affirmé que la combinaison de max-age=0 et must-revalidate a la même signification que no-cache .

Cache-Control: max-age=0, must-revalidate 

max-age=0 signifie que le réponse est immédiatement périmée, et must-revalidate signifie qu'il doit pas être réutilisé sans revalidation une fois qu'il est périmé. combinaison, la sémantique semble être la même que celle de l'expression no-cache .

Cependant, cette utilisation de max-age=0 est un vestige du fait que de nombreux implémentations antérieures à HTTP/1.1 n'étaient pas en mesure de gérer le caractère no-cache et donc de faire face à cette limitation, max-age=0 a été utilisé comme comme solution de rechange.

Mais maintenant que les serveurs conformes à HTTP/1.1 sont largement déployés, il n'y a aucune raison d'utiliser cette max-age=0 -et- must-revalidate combinaison - vous devriez plutôt utiliser no-cache .

Pour référence (pour notre propre contrôle de cache personnel, heh) cette page MDN a été mise à jour pour la dernière fois le 1er juin 2022 ; et j'ai tiré cette citation le 10 juin 2022 ( archives 8 juin ).

Answer 5

D'accord avec une partie de la réponse de @Jeffrey Fox :

max-age=0, must-revalidate et no-cache ne sont pas exactement identiques.

Pas d'accord avec cette partie :

Avec no-cache, il n'afficherait que le contenu en cache, ce qui serait probablement préféré par l'utilisateur (mieux vaut avoir quelque chose de périmé que rien du tout).

Que doivent faire les implémentations lorsque cache-control: no-cache La revalidation échouée n'est tout simplement pas spécifiée dans le document RFC. Tout dépend des implémentations. Elles peuvent envoyer une erreur 504 comme cache-control: must-revalidate ou simplement servir une copie périmée depuis le cache.