Différence entre no-cache et must-revalidate

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, un cache NE DOIT PAS utiliser la réponse pour satisfaire une requête ultérieure sans une revalidation réussie avec le serveur d’origine. Cela permet à un serveur d’origine d’empêcher la mise en cache même par les caches configurés pour renvoyer des réponses obsolètes aux demandes des clients.

Il incite donc les agents à revalider toutes les réponses.

Par rapport à cela

doit-revalider

Lorsque la directive must-revalidate est présente dans une réponse reçue par un cache, ce cache NE DOIT PAS utiliser l’entrée après qu’il est devenu obsolète pour répondre à une requête ultérieure sans d’abord le revalider avec le serveur d’origine.

Il incite donc les agents à revalider les réponses obsolètes .

En particulier en ce qui concerne no-cache , est-ce que les agents utilisateurs traitent de manière empirique cette directive?

Quel est le but de no-cache s’il y a must-revalidate et max-age ?

Voir ce commentaire:

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

no-cache

Bien que cette directive semble indiquer au navigateur de ne pas mettre la page en cache, 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 mise en cache par le navigateur n’a pas changé, le serveur le signale simplement au navigateur et la page est affichée à partir du cache. Par conséquent, le navigateur (au moins en théorie) stocke la page dans son cache, mais l’affiche uniquement après la revalidation avec le serveur. En pratique, IE et Firefox ont commencé à traiter la directive no-cache comme si elle ordonnait 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 cette modification a été provoquée par l’utilisation généralisée (et incorrecte) de cette directive pour empêcher la mise en cache.

Quelqu’un a-t-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 le fait de ne pas valider une demande 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 à coeur jusqu’à maintenant. La RFC dit de ne pas utiliser le must-revalider à la légère. La chose est, avec les services Web, vous devez prendre un avis négatif et assumer le pire pour vos applications clientes inconnues. Toute ressource périmée est susceptible 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 les ETags, j’ai observé que Chrome au moins semble revalider à chaque demande. Ce qui rend les deux directives sans object ou au moins mal nommées car elles ne peuvent pas être validé à nouveau à moins que la requête n’inclue également d’autres en-têtes qui provoquent une «revalidation permanente» de toute façon.

Je veux juste clarifier ce dernier point. En définissant uniquement must-revalidate mais sans inclure un ETag ou Last-Modified, l’agent ne peut récupérer le contenu que s’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 modifiées ou ETag sont incluses dans les réponses, les agents revalorisent toujours de toute façon, indépendamment de la présence de l’en must-revalidate tête must-revalidate .

Donc, le but de must-revalidate est de forcer un «cache de contournement» quand il est périmé, ce qui ne peut se produire que si vous définissez une durée de vie / âge. Si must-revalidate est défini sur une réponse sans âge ou autre en-tête, il devient effectivement équivalent à no-cache puisque la réponse sera considérée immédiatement périmée.

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

Je pense que la must-revalidate signifier “une fois que le cache a expiré, refuser de retourner les réponses obsolètes à l’utilisateur même s’il dit que les réponses obsolètes sont acceptables”. Considérant que no-cache implique must-revalidate plus le fait que la réponse devient périmée tout de suite.

Si une réponse peut être mise en cache pendant 10 secondes, alors must-revalidate est must-revalidate au bout de 10 secondes, alors que no-cache implique la must-revalidate bout de 0 seconde.

Au moins, c’est mon interprétation.

max-age=0, must-revalidate et 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 , il ne ferait que montrer le contenu en cache, ce qui serait probablement préféré par l’utilisateur (il vaut mieux avoir quelque chose de périmé que rien). C’est pourquoi must-revalidate est 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 que no-cache a le même comportement que must-revalidate , ils n’utiliseront PAS le cache local lorsque le serveur est inaccessible, et ils utiliseront tous le cache tout en appuyant sur le bouton Précédent / Suivant du navigateur lorsque le serveur est inaccessible. Comme ci-dessus, je pense que max-age=0, must-revalidate est identique à no-cache , au moins dans l’implémentation.

Je pense qu’il y a une différence entre max-age=0, must-revalidate et no-cache :

Dans le cas du must-revalidate , le client est autorisé à envoyer une demande If-Modified-Since et à envoyer la réponse du cache si 304 Not Modified est renvoyé.

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