L’en-tête implique que le contenu est considéré comme périmé (et doit être ré-captée) immédiatement, qui est en fait la même chose que .
Google n’a pas réussi à résoudre ce mystère pour moi :(
Réponses
Trop de publicités?
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écidé...
Il y a deux côtés à l' Cache-Control - tête. Un côté est où il peut être envoyé par le serveur web (aka. "serveur d'origine"). De l'autre côté, où il peut être envoyé par le navigateur (aka. "agent utilisateur").
Lorsqu'il est envoyé par le serveur d'origine
Je crois max-age=0 indique simplement les caches (et les agents utilisateurs) la réponse est vicié à partir de l'obtenir-aller, et donc, ils DEVRAIENT revalider la réponse (par exemple. avec l' If-Not-Modified - tête) avant d'utiliser une copie mise en cache, alors que, no-cache leur dit qu'ils DOIVENT le valider à nouveau avant d'utiliser une copie mise en cache. De 14.9.1 Ce qui est mis en Cache:
no-cache
...un cache ne DOIT PAS utiliser la réponse pour satisfaire une demande ultérieure sans succès revalidation 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 les demandes.
En d'autres termes, les caches peuvent parfois choisir d'utiliser un état de la réponse (bien que je crois qu'ils ont pour les ajouter un Warning - tête), mais no-cache dit qu'ils ne sont pas autorisés à utiliser un état de réponse, peu importe quoi. Peut-être que vous voulez le DEVRAIT-revalidate comportement lors de baseball statistiques sont générées dans une page, mais vous voulez le DOIT-revalidate comportement lorsque vous avez généré la réponse à un e-commerce d'achat.
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 une autre différence lors de l'utilisation d' no-cache. Je suis tombé sur une page, Cache les Directives de Contrôle d'Démystifiée, qui dit (je ne peux pas se porter garant de son exactitude):
Dans la pratique, IE et Firefox a commencé à traiter le no-cache la directive comme s'il ordonne à l' navigateur de ne pas le cache de la page. Nous avons commencé par 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) de l'utilisation de ce directive pour empêcher la mise en cache.
...
Notez que de la fin, "cache-control: no-cache" a également commencé à se comporter comme le "no-store" de la directive.
En aparté, il me semble que l' Cache-Control: max-age=0, must-revalidate devrait dire la même chose que Cache-Control: no-cache. Peut-être que c'est un moyen d'obtenir le DOIT-revalidate comportement de l' no-cache, tout en évitant l'apparente migration d' no-cache à faire la même chose que no-store (ie. pas de mise en cache que ce soit)?
Lors de l'envoi par l'agent utilisateur
Je crois shahkalpesh réponse s'applique à l'agent utilisateur de côté. Vous pouvez aussi regarder 13.2.6 Disambiguating Réponses Multiples.
Si un agent utilisateur envoie une requête avec Cache-Control: max-age=0 (aka. "de bout en bout, de la revalidation"), puis chaque cache le long de la façon de revalider son entrée de cache (par exemple. avec l' If-Not-Modified - tête) tout le chemin vers le serveur d'origine. Si la réponse est alors 304 (Non Modifié), l'entité du cache peut être utilisé.
D'autre part, l'envoi d'une demande avec l' Cache-Control: no-cache (aka. "de bout en bout reload") n'a pas de revalider et le serveur ne DOIT PAS utiliser une copie mise en cache lors de la réponse.
El Yobo
Points
7580
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 va utiliser la dernière version lors de l'affichage d'une ressource sur un arrière/vers l'avant de la presse. Si no-cache est utilisé, la ressource sera refetched.
Plus de détails sur IE9 mise en cache peut être vu sur ce site msdn de mise en cache blog.
rmalayter
Points
323
Dans mes derniers tests avec IE8 et Firefox 3.5, il semble que les deux sont conformes à la RFC. Cependant, ils diffèrent dans leur "amitié" pour le serveur d'origine. IE8 friandises no-cache réponses avec la même sémantique que l' max-age=0,must-revalidate. Firefox 3.5, cependant, semble considérer no-cache comme équivalent à no-store, qui suce 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 no-cache - tête, tout comme Firefox.
Mon conseil serait de fixer public,max-age=0 pour les non-sensibles ressources que vous voulez avoir vérifié la fraîcheur à chaque requête, mais permettent tout de même de la performance et de la bande passante des avantages de la mise en cache. Par utilisateur les éléments avec le même compte, utilisez private,max-age=0.
Je voudrais éviter l'utilisation de no-cache entièrement, il semble qu'il a été métisser par certains navigateurs populaires et des caches pour l'équivalent fonctionnel de l' no-store.
En outre, ne pas émuler Akamai et Limelight. Alors qu'ils sont essentiellement courir massif de la mise en cache des tableaux comme leur activité principale, et doivent être des experts, en fait, ils ont un intérêt personnel dans la cause de plus de données pour être téléchargé à 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 de façon aléatoire en fonction de la ressource.
shahkalpesh
Points
21553
max-age Lorsqu'un intermédiaire cache est forcé, par le biais d'un max-age=0 de la directive, à revalider sa propre entrée de cache, et le client a fourni son propre programme de validation de la demande, la fourni validateur peut différer du validateur actuellement stockés à l'entrée du cache. Dans ce cas, le cache PEUT utiliser le validateur en faisant sa propre demande sans affectant la sémantique de la transparence. Cependant, le choix de validateur peut affecter les performances. La meilleure approche est pour l' cache intermédiaire de l'utilisation de son propre programme de validation lors de la prise de sa demande. Si le serveur répond avec 304 (Non Modifié), puis le cache peut renvoyer sa copie validée pour le client avec une réponse 200 (OK). Si le serveur répond avec une nouvelle entité et le cache validateur, toutefois, l'intermédiaire cache peut comparer les retournés validateur avec celui fourni dans la demande du client, à l'aide de la forte fonction de comparaison. Si le client valideur l'égalité à l'origine du serveur, puis le cache intermédiaire renvoie simplement 304 (Pas Modifié). Sinon, elle retourne la nouvelle entité avec une réponse 200 (OK). Si une demande inclut la directive no-cache, il ne DEVRAIT PAS inclure min-frais, max-stale, ou 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 :)
Hank Gay
Points
36173
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.
Basé sur 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 arrivées au même moment où "même temps" signifie assez proche ensemble, ils semblent simultanés au cache, mais no-cache ne le ferait pas.
