À 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!