Quelle est la différence entre Cache-Control: max-age = 0 et no-cache?

L'en-tête Cache-Control: max-age=0implique 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.

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

L'en- Cache-Controltête comporte deux côtés . D'un côté, il peut être envoyé par le serveur Web (alias "serveur d'origine"). L'autre côté est l'endroit où il peut être envoyé par le navigateur (alias «agent utilisateur»).

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

Je pense max-age=0simplement dire aux caches (et aux agents utilisateurs) que la réponse est périmée dès le départ et qu'ils DEVRAIENT donc revalider la réponse (par exemple avec l'en- If-Not-Modifiedtête) avant d'utiliser une copie en cache, tandis que, no-cacheleur dire qu'ils DOIVENT revalider avant d'utiliser une mémoire cache copie. À partir de 14.9.1 Qu'est-ce qui peut être mis en cache :

pas de cache

... un cache NE DOIT PAS utiliser la réponse pour satisfaire une demande suivante 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.

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 un en- Warningtête), mais no-cachedisent qu'ils ne sont pas autorisés à utiliser une réponse périmée quoi qu'il arrive . Vous voudrez peut-être le comportement DEVRAIT -revalider lorsque les statistiques de baseball sont générées dans une page, mais vous voudriez le comportement DOIT -revalider lorsque vous avez généré la réponse à un achat de commerce électronique.

Bien que vous ayez raison dans votre commentaire lorsque vous dites que ce no-cachen'est pas censé empêcher le stockage, cela pourrait en fait être une autre différence lors de l'utilisation no-cache. Je suis tombé sur une page, Cache Control Directives Demystified , qui dit (je ne peux pas garantir son exactitude):

Dans la 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. 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.

...

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

Soit dit en passant, il me semble que cela Cache-Control: max-age=0, must-revalidatedevrait signifier essentiellement la même chose que Cache-Control: no-cache. Alors peut-être que c'est un moyen d'obtenir le comportement MUST -revalidate de no-cache, tout en évitant la migration apparente de no-cachefaire la même chose que no-store(c.-à-d. Pas de mise en cache quelle qu'elle soit)?

Lorsqu'il est envoyé par l'agent utilisateur

Je crois que la réponse de shahkalpesh s'applique au côté agent utilisateur. Vous pouvez également consulter 13.2.6 Désambiguïser les réponses multiples .

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

D'un autre côté, l'envoi d'une demande 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 lors de la réponse.

âge max = 0

Cela équivaut à cliquer sur Actualiser , ce qui signifie, donnez-moi la dernière copie, sauf si j'ai déjà la dernière copie.

pas de cache

Cela permet de maintenir la touche Maj enfoncée tout en cliquant sur Actualiser, ce qui signifie qu'il suffit de tout refaire quoi qu'il arrive.

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

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

Dans mes tests récents avec IE8 et Firefox 3.5, il semble que les deux soient conformes à la RFC. Cependant, ils diffèrent par leur «convivialité» par rapport au serveur d'origine. IE8 traite les no-cacheréponses avec la même sémantique que max-age=0,must-revalidate. Firefox 3.5, cependant, semble être considéré no-cachecomme équivalent à no-store, ce qui est nul pour les performances et l'utilisation de la bande passante.

Squid Cache, par défaut, ne semble jamais rien stocker avec un en- no-cachetête, tout comme Firefox.

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

J'éviterais l'utilisation de no-cacheentièrement, car il semble qu'il a été bâtardé par certains navigateurs et caches populaires pour l'équivalent fonctionnel de no-store.

De plus, n'émulez pas Akamai et Limelight. Bien qu'ils exécutent essentiellement des matrices de mise en cache massives comme activité principale et devraient être des experts, ils ont en fait un intérêt à faire télécharger plus de données à partir de leurs réseaux. Google n'est peut-être pas non plus un bon choix pour l'émulation. Ils semblent utiliser max-age=0ou no-cacheau hasard selon la ressource.

âge max
    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 demande, 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 des valideurs pour faire sa propre demande sans 
affectant la transparence sémantique. 

    Cependant, le choix du validateur peut affecter les performances. La meilleure approche consiste à
cache intermédiaire pour utiliser son propre validateur lors de sa demande. 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 nouveau validateur de cache,
cependant, le cache intermédiaire peut comparer le validateur retourné 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 (pas 
Modifié). Sinon, il renvoie la nouvelle entité avec une réponse 200 (OK).

    Si une demande inclut la directive no-cache, elle NE DEVRAIT PAS inclure min-fresh, 
max-rassis, ou max-âge. 

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

N'acceptez pas cela comme réponse - je vais devoir le lire pour comprendre sa véritable utilisation :)

Je ne suis guère un expert 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=0le cache puisse envoyer une réponse en cache aux demandes qui sont arrivées en "même temps", où "en même temps" signifie assez proches les uns des autres, ils semblent simultanés au cache, mais no-cachene le feraient pas .

Soit dit en passant, il convient de noter que certains appareils mobiles, en particulier les produits Apple comme l'iPhone / iPad, ignorent complètement les en-têtes comme no-cache, no-store, Expires: 0, ou quoi que ce soit d'autre que vous puissiez essayer de les forcer à ne pas réutiliser expiré pages de formulaire.

Cela ne nous a causé aucun mal de tête alors que nous essayons de résoudre le problème de l'iPad d'un utilisateur, endormi sur une page qu'il a atteinte via un processus de formulaire, disons l'étape 2 sur 3, puis l'appareil ignore totalement le magasin / les directives de cache, et pour autant que je sache, prennent simplement ce qui est un instantané virtuel de la page de son dernier état, c'est-à-dire en ignorant ce qui lui a été dit explicitement, et, non seulement cela, en prenant une page qui ne devrait pas être stockée , et le stocker sans le vérifier à nouveau, ce qui entraîne entre autres toutes sortes de problèmes de Session étranges.

J'ajoute juste cela au cas où quelqu'un viendrait et ne pourrait pas comprendre pourquoi ils obtiennent 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 des tests de débogage assez approfondis avec ce problème, et c'est ma conclusion, les appareils ignorent complètement ces directives.

Même en utilisation régulière, j'ai constaté que certains mobiles ne parviennent pas à vérifier les nouvelles versions via, par exemple, Expire: 0, puis vérifient les dernières dates modifiées pour déterminer s'il devrait en obtenir une nouvelle.

Cela ne se produit tout simplement pas, alors ce que j'ai été forcé de faire était d'ajouter des chaînes de requête aux fichiers css / js sur lesquels j'avais besoin de forcer les mises à jour, ce qui incite les stupides appareils mobiles à penser que c'est un fichier qu'il n'a pas, comme: mon .css? v = 1, puis v = 2 pour une mise à jour css / js. Cela fonctionne largement.

Par ailleurs, les navigateurs des utilisateurs, s'ils sont laissés à leurs valeurs par défaut, à partir de 2016, comme je le découvre en permanence (nous faisons BEAUCOUP de changements et de mises à jour sur notre site), ne vérifient pas non plus les dernières dates modifiées sur ces fichiers, mais la requête La méthode des chaînes résout ce problème. C'est quelque chose que j'ai remarqué avec des clients et des employés de bureau qui ont tendance à utiliser les valeurs par défaut de l'utilisateur normal de base sur leurs navigateurs, et qui n'ont pas conscience des problèmes de mise en cache avec css / js, etc., échouent presque toujours à obtenir les nouveaux css / js sur le changement, ce qui signifie que les paramètres par défaut de leurs navigateurs, principalement MSIE / Firefox, ne font pas ce qu'on leur dit de faire, ils ignorent les changements et ignorent les dernières dates modifiées et ne valident pas, même avec Expires: 0 défini explicitement.

C'était un bon fil avec beaucoup de bonnes informations techniques, mais il est également important de noter à quel point le support 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 incapacité à suivre les commandes d'en-tête qu'ils reçoivent ou à interpréter correctement ces commandes.

Une chose qui (étonnamment) n'a pas été mentionnée est qu'une demande peut explicitement indiquer qu'elle acceptera des données périmées, en utilisant la max-staledirective. Dans ce cas, si le serveur répondait par max-age=0, le cache considérerait simplement la réponse périmée et serait libre de l'utiliser pour satisfaire la demande du client [qui demandait des données potentiellement périmées]. En revanche, si le serveur envoie, no-cachecela l'emporte vraiment sur toute demande du client (avec max-stale) pour des données périmées, car le cache DOIT revalider.

La différence est que no-cache (no-store sur Firefox) empêche tout type de mise en cache. Cela peut être utile pour empêcher l'écriture de pages avec un contenu sécurisé sur le disque et pour les pages qui doivent toujours être mises à jour même si elles sont revisitées 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 être mis à jour tant que le site n'est pas visité dans une nouvelle session.

Habituellement, les navigateurs ne suppriment pas les entrées de cache expirées, sauf s'ils récupèrent de 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.