Quelle est la différence entre Cache-Control: max-age=0 et no-cache?
l'en-tête Cache-Control: max-age=0 implique que le contenu est considéré comme périmé (et doit être récupéré) immédiatement, ce qui est en fait la même chose que Cache-Control: no-cache .
9 réponses
j'ai eu cette même question, et trouvé des infos dans mes recherches (votre question s'est posée comme l'un des résultats). Voici ce que j'ai déterminé...
il y a deux côtés à l'en-tête Cache-Control . Un côté est où il peut être envoyé par le serveur web (aka. "serveur d'origine"). L'autre côté est où il peut être envoyé par le navigateur (alias. "agent utilisateur").
Lorsqu'il est envoyé par le serveur d'origine
Je crois que max-age=0 dit tout simplement caches (et les agents utilisateurs) la réponse est périmée à partir du get-go et donc ils devrait revalider la réponse (par ex. avec l'en-tête If-Not-Modified ) avant d'utiliser une copie mise en cache, alors que no-cache leur dit qu'ils doivent revalider avant d'utiliser une copie mise en cache. De 14.9.1 Qu'est-ce qui peut être mis en cache :
no-cache
...un cache 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 pour empêcher la mise en cache même par des caches qui ont été configurés pour retour rassis réponses aux clients demande.
en d'autres termes, les caches peuvent parfois choisir d'utiliser une réponse périmée (bien que je crois qu'ils doivent alors ajouter un en-tête Warning ), mais no-cache dit qu'ils ne sont pas autorisés à utiliser une réponse périmée quoi qu'il arrive. Peut-être que vous voulez le devrait - revalidate comportement lorsque les statistiques de baseball sont générés dans une page, mais vous voulez le doit -revalidate comportement lorsque vous avez généré la réponse à un achat e-commerce.
bien que vous avez raison dans votre commentaire quand vous dites no-cache n'est pas censé empêcher le stockage, il pourrait en fait être un autre différence lors de l'utilisation de no-cache . Je suis tombé sur une page, les directives de contrôle de Cache démystifiées , qui dit (Je ne peux pas garantir son exactitude):
en pratique, IE et Firefox ont commencé à traiter le no-cache la directive comme s'il ordonne à l' navigateur pour ne pas même mettre en cache la page. Nous avons commencé à observer ce comportement il ya environ un an. Nous soupçonnons que ce changement a été invité par le généralisée (et erronée) utilisation de ce directive pour empêcher la mise en cache.
...
Avis que de la fin, "cache-control: no-cache" a également commencé à se comporter comme la directive "no-store".
entre parenthèses, il me semble que Cache-Control: max-age=0, must-revalidate devrait signifier essentiellement la même chose que Cache-Control: no-cache . Donc peut-être que c'est une façon d'obtenir le doit - revalidate comportement de no-cache , tout en évitant l'apparente migration de no-cache à faire la même chose que no-store (c.-à-d. pas de mise en cache que ce soit)?
Lors de l'envoi par l'agent utilisateur
je crois shahkalpesh la réponse de s'applique à l'agent utilisateur de côté. Vous pouvez également regarder 13.2.6 Disambiguating Réponses Multiples .
si un agent utilisateur envoie une requête avec Cache-Control: max-age=0 (alias. "de bout en bout revalidation"), puis chaque cache le long du chemin va revalider son entrée de cache (par ex. avec l'en-tête If-Not-Modified ) jusqu'au serveur d'origine. Si la réponse est alors 304 (Non Modifié), l'entité du cache peut être utilisé.
d'autre part, en envoyant une demande avec Cache-Control: no-cache (alias. "end-to-end reload") ne revalide pas et le serveur ne doit pas utiliser de copie en cache pour répondre.
max-age=0
cela équivaut à cliquer sur rafraîchir , ce qui signifie, Donnez-moi la dernière copie à moins que je n'ai déjà la dernière copie.
no-cache
ça tient Maj tout en cliquant rafraîchir, ce qui veut dire, tout recommencer quoi qu'il arrive.
Vieille question maintenant, mais si quelqu'un d'autre vient à travers à travers une recherche que j'ai fait, il apparaît que IE9 sera de faire usage de ce pour configurer le comportement de ressources lorsque vous utilisez les boutons précédent et suivant. Lorsque max-age=0 est utilisé, le navigateur utilisera la dernière version lors de l'affichage d'une ressource sur une presse back/forward. Si no-cache est utilisé, la ressource sera reformatée.
plus de détails sur IE9 la mise en cache peut être vue sur ce msdn caching blog post .
dans mes récents tests avec IE8 et Firefox 3.5, il semble que les deux sont conformes RFC. Cependant, ils diffèrent dans leur "amitié" pour le serveur d'origine. IE8 traite les réponses no-cache avec la même sémantique que max-age=0,must-revalidate . Firefox 3.5, cependant, semble traiter no-cache comme l'équivalent de no-store , ce qui craint pour la performance et l'utilisation de la bande passante.
Squid Cache, par défaut, semble ne jamais stocker quoi que ce soit avec un en-tête no-cache , tout comme Firefox.
mon conseil serait de définir public,max-age=0 pour les ressources non-sensibles que vous voulez avoir vérifié pour la fraîcheur sur chaque demande, mais permettre tout de même les performances et les avantages de bande passante de la mise en cache. Pour les articles par utilisateur avec la même considération, utilisez private,max-age=0 .
je voudrais éviter l'utilisation de no-cache , puisqu'il semble qu'elle ait été métisser par certains navigateurs populaires et des caches pour l'équivalent fonctionnel de no-store .
en outre, ne pas imiter Akamai et Limelight. Bien qu'ils exécutent essentiellement des réseaux de mise en cache massive comme leur activité principale, et devrait être des experts, ils ont en fait un intérêt direct à faire plus de données à télécharger à partir de leurs réseaux. Google pourrait ne pas être un bon choix pour l'émulation, soit. Ils semblent utiliser max-age=0 ou no-cache au hasard selon la ressource.
max-age
When an intermediate cache is forced, by means of a max-age=0 directive, to revalidate
its own cache entry, and the client has supplied its own validator in the request, the
supplied validator might differ from the validator currently stored with the cache entry.
In this case, the cache MAY use either validator in making its own request without
affecting semantic transparency.
However, the choice of validator might affect performance. The best approach is for the
intermediate cache to use its own validator when making its request. If the server replies
with 304 (Not Modified), then the cache can return its now validated copy to the client
with a 200 (OK) response. If the server replies with a new entity and cache validator,
however, the intermediate cache can compare the returned validator with the one provided in
the client's request, using the strong comparison function. If the client's validator is
equal to the origin server's, then the intermediate cache simply returns 304 (Not
Modified). Otherwise, it returns the new entity with a 200 (OK) response.
If a request includes the no-cache directive, it SHOULD NOT include min-fresh,
max-stale, or max-age.
courtoisie: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.4
Ne pas accepter cette réponse - je vais le lire pour comprendre la véritable utilisation de celui-ci :)
Je ne suis pas un expert en cache, mais Mark Nottingham l'est. Voici son caching docs . Il a également d'excellents liens dans la section Références.
D'après ma lecture de ces docs, il semble que max-age=0 pourrait permettre au cache d'envoyer une réponse en cache aux requêtes qui sont arrivées" en même temps "où" en même temps "signifie suffisamment proche les unes des autres qu'elles semblent simultanées au cache, mais no-cache ne le ferait pas.
soit dit en passant, il est intéressant de noter que certains appareils mobiles, en particulier Les produits Apple comme iPhone/iPad complètement ignorer les en-têtes comme no-cache, no-store, expire: 0, ou tout autre que vous pouvez essayer de les forcer à ne pas réutiliser les pages de formulaire expirées.
cela ne nous a pas causé de fin de maux de tête que nous essayons d'obtenir la question de l'iPad d'un utilisateur dire, étant laissé endormi sur une page qu'ils ont atteint à travers un processus de forme, disons étape 2 de 3, et puis l'appareil ignore totalement la magasin/cache directives, et aussi loin que je peux dire, simplement prend un cliché de la page à partir de son dernier état, qui est, en ignorant ce qu'il a dit explicitement, et pas seulement que, en prenant une page qui ne doit pas être stockée, et de les stocker sans les vérifier de nouveau, ce qui conduit à toutes sortes d'étranges Session de questions, parmi d'autres choses.
j'ajoute juste ceci au cas où quelqu'un arrive et ne peut pas comprendre pourquoi ils ont des erreurs de session avec en particulier les iphones et les ipads, qui semblent de loin être les pires contrevenants dans ce domaine.
j'ai fait assez de tests de débogage avec ce problème, et c'est ma conclusion, les appareils ignorent complètement ces directives.
même dans l'utilisation régulière, j'ai trouvé que certains mobiles aussi totalement ne parviennent pas à vérifier les nouvelles versions via say, expire: 0 puis en vérifiant les dernières dates modifiées pour déterminer si elle devrait obtenir une nouvelle.
Cela ne se produit tout simplement pas, donc ce que j'ai été forcé de faire était d'ajouter des chaînes de requête aux fichiers css/js dont j'avais besoin pour forcer les mises à jour, ce qui astucieux les appareils mobiles stupides en pensant que c'est un fichier qu'il n'a pas, comme: mon.css?v=1, puis v=2 pour une mise à jour css/js. Cette mesure fonctionne.
navigateurs utilisateurs aussi, soit dit en passant, si laissé à leurs valeurs par défaut, à partir de 2016, comme je le découvre en permanence (nous faisons beaucoup de changements et de mises à jour de notre site) ne parviennent pas non plus à vérifier les dernières dates modifiées sur de tels fichiers, mais la chaîne de requête méthode résout le problème. C'est quelque chose que j'ai remarqué avec les clients et les gens de bureau qui ont tendance à utiliser les utilisateurs normaux de base par défaut sur leurs navigateurs, et n'ont aucune conscience des problèmes de mise en cache avec css/js etc, presque invariablement ne parviennent pas à obtenir le nouveau css/js sur le changement, ce qui signifie que les défauts pour leurs navigateurs, principalement MSIE / Firefox, ne font pas ce qu'on leur dit de faire, ils ignorent les changements et ignorer les dernières dates modifiées et ne valident pas, même avec Expires: 0 définir explicitement.
c'était un bon fil avec beaucoup de bonnes informations techniques, mais il est également important de noter à quel point le soutien pour ce genre de choses est mauvais dans les appareils mobiles en particulier. Tous les quelques mois, je dois ajouter plus de couches de protection contre leur échec à suivre les commandes d'en-tête qu'ils reçoivent, ou pour interpeller correctement ces commandes.
voici un petit arbre de décision qui, je l'espère, clarifiera la différence.
la différence est que no-cache (no-store on Firefox) empêche tout type de cache. Cela peut être utile pour empêcher les pages avec du contenu sécurisé étant écrit sur le disque et pour les pages qui doivent toujours être mis à jour, même si elles sont re-visités avec le bouton de retour.
max-age=0 indique qu'une entrée de cache est périmée et nécessite une nouvelle validation, mais n'empêche pas la mise en cache. Souvent, les navigateurs ne valident les ressources qu'une seule fois par session de navigateur, de sorte que le contenu peut ne pas obtenir mis à jour jusqu'à ce que le site soit visité dans une nouvelle session.
habituellement, les navigateurs ne suppriment pas les entrées de cache expirées, à moins qu'ils ne récupèrent l'espace pour du contenu plus récent lorsque le cache du navigateur est plein. En utilisant no-store, no-cache permet de supprimer explicitement une entrée de cache.