Différence entre no-cache et must-revalidate

À partir de la RFC 2616

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

pas de cache

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

Donc, il ordonne aux agents de revalider tout réponses.

Comparé à

doit revalider

Lorsque la directive must-revalidate est présente dans une réponse reçue par une antémémoire, cette antémémoire NE DOIT PAS utiliser l'entrée une fois qu'elle est devenue obsolète pour répondre à une demande ultérieure sans la revalider d'abord avec le serveur d'origine

Donc, il ordonne aux agents de revalider les vieux réponses .

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

À quoi sert no-caches'il y a must-revalidateet max-age?

Voir ce commentaire:

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

pas de cache

Bien que cette directive semble indiquer au navigateur de ne pas mettre en cache la page, il existe une différence subtile. La directive «no-cache», selon la RFC, indique au navigateur qu'il doit revalider avec le serveur avant de servir la page à partir du cache. La revalidation est une technique soignée qui permet à l'application de conserver la bande passante. Si la page que le navigateur a mise en cache n'a pas changé, le serveur le signale simplement au navigateur et la page est affichée à partir du cache. Ainsi, le navigateur (du moins en théorie) stocke la page dans son cache, mais ne l'affiche qu'après la revalidation auprès du serveur. En pratique, IE et Firefox ont commencé à traiter la directive no-cache comme si elle demandait au navigateur de ne même pas mettre en cache la page. Nous avons commencé à observer ce comportement il y a environ un an.

Quelqu'un at-il quelque chose de plus officiel à ce sujet?

Mettre à 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 silencieusement non exécutée.

C'est quelque chose que je n'ai jamais pris à cœur jusqu'à présent. La RFC dit de ne pas utiliser la revalidation à la légère. Le fait est qu'avec les services Web, vous devez avoir 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.

Et autre chose que je viens de considérer, sans Last-Modified ou ETags, le navigateur ne peut récupérer que la totalité de la ressource. 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 car elles ne peuvent pas être correctement revalidées à moins que la demande n'inclue également d'autres en-têtes qui provoquent de toute façon «toujours revalider».

Je veux simplement clarifier ce dernier point. En définissant simplement must-revalidatemais sans inclure un ETag ou Last-Modified, l'agent ne peut que récupérer le contenu car il n'a rien à envoyer au serveur pour le comparer.

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

Donc, le but de must-revalidateest de forcer un `` cache de contournement '' quand il devient obsolète, ce qui ne peut se produire que lorsque vous avez défini une durée de vie / âge, donc si must-revalidateest défini sur une réponse sans âge ou autres en-têtes, cela devient effectivement équivalent à no-cachepuisque la réponse sera considérée comme immédiatement périmée.

- Alors je vais enfin marquer la réponse de Gili!

Je crois que cela must-revalidatesignifie:

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

Alors que cela no-cacheimplique:

must-revalidate en plus du fait que la réponse devient immédiatement périmée.

Si une réponse peut être mise en cache pendant 10 secondes, elle se must-revalidatedéclenche après 10 secondes, alors que cela no-cacheimplique must-revalidateaprès 0 seconde.

Du moins, c'est mon interprétation.

max-age=0, must-revalidateet no-cachene 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, cela afficherait simplement le contenu mis en cache, ce qui serait probablement préféré par l'utilisateur (mieux vaut avoir quelque chose de périmé que rien du tout). C'est pourquoi must-revalidateest destiné uniquement aux transactions critiques.

Avec l'interprétation de Jeffrey Fox à propos de no-cache, j'ai testé sous chrome 52.0.2743.116 m, le résultat montre qu'il no-cachea le même comportement que must-revalidate, ils n'utiliseront PAS tous le cache local lorsque le serveur est inaccessible, et, ils utiliseront tous le cache pendant que le navigateur tapera Retour / Bouton de transfert lorsque le serveur est inaccessible. Comme ci-dessus, je pense que max-age=0, must-revalidatec'est identique à no-cache, au moins dans la mise en œuvre.

Je pense qu'il y a une différence entre max-age=0, must-revalidateetno-cache :

Dans le must-revalidatecas où le client est autorisé à envoyer une If-Modified-Sincedemande et à servir la réponse à partir du cache si304 Not Modified est renvoyée.

Dans ce no-cachecas, le client ne doit pas mettre en cache la réponse, il ne doit donc pas utiliser If-Modified-Since.