229 votes

Différence entre no-cache et must-revalidate

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 !

-2voto

Rich Points 1870

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

Dans le must-revalidate dans le cas où le client est autorisé à envoyer un If-Modified-Since et servir la réponse à partir du cache si 304 Not Modified est renvoyé.

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

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X