Question 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.


528
2018-06-26 01:34


origine


Réponses:


J'ai eu cette même question, et j'ai trouvé quelques informations dans mes recherches (votre question est apparue comme l'un des résultats). Voici ce que j'ai déterminé ...

Il y a deux côtés à la Cache-Control entête. 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 "user agent").


Lorsqu'il est envoyé par le serveur d'origine

Je crois max-age=0 indique simplement aux caches (et aux agents utilisateurs) que la réponse est périmée dès le départ et qu'ils DEVRAIT revalider la réponse (par exemple avec le If-Not-Modified en-tête) avant d'utiliser une copie en cache, alors que no-cache leur dit qu'ils DOIT revalider avant d'utiliser une copie en cache. De 14.9.1 Qu'est-ce que Cacheable:

pas de cache

... un cache NE DOIT PAS utiliser la réponse   pour satisfaire une demande ultérieure   sans revalidation avec succès   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   retourner les réponses périmées au client   demandes

En d'autres termes, les caches peuvent parfois choisir d'utiliser une réponse périmée (bien que je pense qu'ils doivent ensuite ajouter une Warning en-tête), mais no-cache dit qu'ils ne sont pas autorisés à utiliser une réponse éventée, peu importe quoi. Peut-être que vous voulez le DEVRAIT-valide le comportement lorsque les statistiques de baseball sont générées dans une page, mais vous souhaitez que DOIT-valide le comportement lorsque vous avez généré la réponse à un achat e-commerce.

Bien que vous ayez raison dans votre commentaire quand vous dites no-cache n'est pas censé empêcher le stockage, il pourrait effectivement être une autre différence lors de l'utilisation no-cache. Je suis tombé sur une page, Directives de contrôle du cache démystifiées, cela dit (je ne peux pas garantir son exactitude):

En pratique, IE et Firefox ont   commencé à traiter le non-cache   directive comme si elle ordonne à la   navigateur pour ne même pas mettre en cache la page.   Nous avons commencé à observer ce comportement   Il ya environ un an. Nous suspectons que   ce changement a été provoqué par le   utilisation répandue (et incorrecte) de cette   directive pour empêcher la mise en cache.

...

Notez que récemment, "cache-control:   no-cache "a également commencé à se comporter   comme la directive "sans magasin".

En aparté, il me semble que Cache-Control: max-age=0, must-revalidate devrait essentiellement signifier la même chose que Cache-Control: no-cache. Alors peut-être que c'est un moyen d'obtenir le DOIT-valider le comportement de no-cache, tout en évitant la migration apparente de no-cache de faire la même chose que no-store (c'est-à-dire aucune mise en cache)?


Lorsqu'il est envoyé par l'agent utilisateur

Je crois La réponse de Shahkalpesh s'applique au côté de l'agent utilisateur. Vous pouvez également regarder 13.2.6 Désambiguïsation de réponses multiples.

Si un agent utilisateur envoie une requête avec Cache-Control: max-age=0 (alias "revalidation de bout en bout"), puis chaque cache en cours de route revalidera son entrée dans le cache (par ex. If-Not-Modifieden-tête) jusqu'au serveur d'origine. Si la réponse est alors 304 (Non Modifié), l'entité mise en cache peut être utilisée.

D'un autre côté, envoyer une requête avec Cache-Control: no-cache (aka "rechargement de bout en bout") ne revalide pas et le serveur NE DOIT PAS utiliser une copie mise en cache en répondant.


513
2017-09-05 13:43



max-age = 0

C'est équivalent à cliquer Rafraîchir, ce qui signifie, donnez-moi la dernière copie sauf si j'ai déjà la dernière copie.

pas de cache 

Cela tient Décalage tout en cliquant sur Actualiser, ce qui signifie, tout simplement refaire tout, peu importe quoi.


35
2018-05-12 03:59



Old question maintenant, mais si quelqu'un d'autre vient à travers cela à travers une recherche comme je l'ai fait, il semble que IE9 utilisera cela pour configurer le comportement des ressources lors de l'utilisation des boutons Précédent et Suivant. Quand max-age = 0 est utilisé, le navigateur utilisera la dernière version lors de la visualisation d'une ressource sur une presse arrière / avant. Si pas de cache est utilisé, la ressource sera récupérée.

De plus amples détails sur la mise en cache d'IE9 peuvent être consultés à ce sujet. msdn mise en cache post de blog.


30
2017-11-27 09:13



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 "convivialité" au serveur d'origine. Gâteries IE8 no-cache réponses avec la même sémantique que max-age=0,must-revalidate. Firefox 3.5, cependant, semble traiter no-cache comme équivalent à no-store, qui craint pour la performance et l'utilisation de la bande passante.

Squid Cache, par défaut, ne semble jamais stocker quelque chose avec un no-cache en-tête, tout comme Firefox.

Mon conseil serait de définir public,max-age=0 pour les ressources non sensibles, vous souhaitez vérifier la fraîcheur à chaque requête, tout en conservant les performances et la bande passante de la mise en cache. Pour les éléments par utilisateur avec la même considération, utilisez private,max-age=0.

J'éviterais l'utilisation de no-cache entièrement, car il semble qu'il a été bastardisé par certains navigateurs et des caches populaires à l'équivalent fonctionnel de no-store.

De plus, n'émulez pas Akamai et Limelight. Bien qu'ils utilisent essentiellement des baies de mise en cache massives comme activité principale et qu'ils soient des experts, ils ont tout intérêt à ce que davantage de données soient téléchargées à partir de leurs réseaux. Google n'est peut-être pas un bon choix pour l'émulation. Ils semblent utiliser max-age=0 ou no-cache au hasard en fonction de la ressource.


23
2018-01-25 23:06



max-age
    Lorsqu'un cache intermédiaire est forcé, au moyen d'une directive max-age = 0, de revalider
sa propre entrée de cache, et le client a fourni son propre validateur dans la requête, le
Le validateur fourni peut différer du validateur actuellement stocké avec l'entrée de cache.
Dans ce cas, le cache PEUT utiliser l'un ou l'autre validateur pour faire sa propre requête sans
affectant la transparence sémantique.

    Cependant, le choix du validateur peut affecter les performances. La meilleure approche est pour le
cache intermédiaire pour utiliser son propre validateur lors de sa requête. Si le serveur répond
avec 304 (non modifié), le cache peut renvoyer sa copie maintenant validée au client
avec une réponse 200 (OK). Si le serveur répond avec une nouvelle entité et un validateur de cache,
cependant, le cache intermédiaire peut comparer le validateur renvoyé avec celui fourni dans
la demande du client, en utilisant la fonction de comparaison forte. Si le validateur du client est
égal au serveur d'origine, le cache intermédiaire renvoie simplement 304 (Non
Modifié). Sinon, il renvoie la nouvelle entité avec une réponse 200 (OK).
Si une requête inclut la directive no-cache, elle NE DEVRAIT PAS inclure min-fresh,
max-stale, ou max-age. 

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

N'acceptez pas cela comme réponse - je devrai le lire pour en comprendre l'utilisation réelle :)


18
2018-06-26 01:44



Je ne suis pas un expert de la mise en cache, mais Mark Nottingham l'est. Voici ses documents de mise en cache. Il a également d'excellents liens dans la section Références.

Sur la base de ma lecture de ces documents, il semble que max-age=0 pourrait permettre au cache d'envoyer une réponse en cache aux demandes qui sont arrivées au même moment où "même heure" signifie assez proche ensemble, ils regardent simultanément à la cache, mais no-cache ne le ferait pas.


11
2018-06-26 01:59



En passant, il convient de noter que certains appareils mobiles, en particulier les produits Apple comme iPhone / iPad ignorent complètement les en-têtes tels que no-cache, no-store, Expires: 0, ou tout ce que vous pouvez essayer de forcer à ne pas réutiliser. pages de formulaire.

Cela nous a causé des maux de tête, car nous essayons d'obtenir le problème de l'iPad d'un utilisateur, en restant endormi sur une page qu'il a atteinte via un processus de formulaire, par exemple étape 2 sur 3, puis l'appareil ignore totalement Les directives de cache, et autant que je peux dire, prennent simplement ce qui est un instantané virtuel de la page de son dernier état, c'est-à-dire, ignorant ce qu'on lui a dit explicitement, et pas seulement, prenant une page qui ne devrait pas être stockée , et de le stocker sans vraiment le vérifier à nouveau, ce qui conduit à toutes sortes de problèmes de session étranges, entre autres choses.

J'ajoute juste ceci au cas où quelqu'un viendrait et ne peut pas comprendre pourquoi ils obtiennent des erreurs de session particulièrement avec iphones et ipads, qui semblent de loin être les pires coupables dans ce secteur.

J'ai fait des tests de débogage assez approfondis avec ce problème, et c'est ma conclusion, les périphériques ignorent complètement ces directives.

Même en utilisation régulière, j'ai constaté que certains mobiles ne vérifiaient pas non plus les nouvelles versions par exemple, Expires: 0 puis vérifiant les dernières dates modifiées pour déterminer si elle devrait en obtenir une nouvelle.

Cela n'a simplement pas eu lieu, et j'ai dû ajouter des chaînes de requête aux fichiers css / js dont j'avais besoin pour forcer les mises à jour, ce qui trompe les stupides appareils mobiles en leur faisant croire que c'est un fichier qu'il n'a pas. .css? v = 1, puis v = 2 pour une mise à jour de css / js. Cela fonctionne largement.

Soit dit en passant, si laissé à leurs défauts, à partir de 2016, comme je le découvre continuellement (nous faisons beaucoup de changements et de mises à jour sur notre site), ne vérifie pas les dernières dates modifiées sur ces fichiers, mais la requête méthode de chaîne corrige ce problème. C'est quelque chose que j'ai remarqué avec les clients et les employés de bureau qui ont tendance à utiliser les valeurs par défaut de leurs navigateurs, et qui ne sont pas conscients des problèmes de cache avec css / js etc, ne parviennent presque jamais à changer les nouveaux css / js, ce qui signifie que les paramètres par défaut de leurs navigateurs, principalement MSIE / Firefox, ne font pas ce qu'on leur dit, ils ignorent les changements et ignorent les dernières dates modifiées et ne les valident pas, même avec Expires: 0 défini explicitement.

Ce fut un bon sujet avec beaucoup de bonnes informations techniques, mais il est également important de noter à quel point le support pour ce genre de matériel est particulièrement important dans les appareils mobiles. Tous les quelques mois, je dois ajouter plus de couches de protection pour ne pas suivre les commandes d'en-tête qu'ils reçoivent, ou pour interpeler correctement ces commandes.


9
2018-04-13 19:49