it-swarm.com.de

Was ist der Unterschied zwischen Cache-Control: max-age = 0 und no-cache?

Der Header Cache-Control: max-age=0 impliziert, dass der Inhalt sofort als veraltet betrachtet wird (und erneut abgerufen werden muss), was praktisch dasselbe ist wie Cache-Control: no-cache.

602
rubyruy

Ich hatte die gleiche Frage und fand einige Informationen in meinen Suchen (Ihre Frage kam als eines der Ergebnisse auf). Folgendes habe ich bestimmt ...

Der Header Cache-Control hat zwei Seiten. Eine Seite ist, wohin es vom Webserver (auch "Ursprungsserver" genannt) gesendet werden kann. Auf der anderen Seite kann es vom Browser gesendet werden (auch bekannt als "User Agent").


Wenn vom Origin-Server gesendet

Ich glaube, max-age=0 teilt Caches (und Benutzeragenten) einfach mit, dass die Antwort von Anfang an veraltet ist und sie SOLLTEN die Antwort erneut validieren (z. B. mit dem If-Not-Modified -Header) vor der Verwendung einer zwischengespeicherten Kopie, während no-cache ihnen mitteilt, dass sie _ erneut validieren müssen , bevor sie eine zwischengespeicherte Kopie verwenden. Von 14.9.1 Was ist Cacheable :

no-cache

... ein Cache DARF NICHT die Antwort verwenden, um eine nachfolgende Anfrage ohne erfolgreiche erneute Validierung mit dem Origin-Server zu erfüllen. Auf diese Weise kann ein Origin-Server das Cachen auch durch Caches verhindern, die so konfiguriert wurden, dass veraltete Antworten auf Clientanforderungen zurückgegeben werden.

Mit anderen Worten, Caches können manchmal eine veraltete Antwort verwenden (obwohl ich glaube, dass sie dann einen Warning -Header hinzufügen müssen), aber no-cache sagt, dass sie keine veraltete Antwort verwenden dürfen, egal Was. Vielleicht möchten Sie, dass das SOLLTE - das Verhalten erneut validiert, wenn Baseball-Statistiken auf einer Seite generiert werden, aber Sie möchten, dass das MUSS - Verhalten erneut validieren, wenn Sie die Antwort auf einen E-Commerce-Kauf generiert haben.

Obwohl Sie in Ihrem Kommentar richtig sind, wenn Sie sagen, dass no-cache die Speicherung nicht verhindern soll, könnte es tatsächlich einen weiteren Unterschied bei der Verwendung von no-cache geben. Ich bin auf eine Seite gestoßen, Cache Control Directives Demystified , die besagt (ich kann nicht für ihre Richtigkeit bürgen):

In der Praxis haben IE und Firefox damit begonnen, die Direktive no-cache so zu behandeln, als würde sie den Browser anweisen, die Seite nicht einmal zwischenzuspeichern. Wir haben vor ungefähr einem Jahr damit begonnen, dieses Verhalten zu beobachten. Wir vermuten, dass diese Änderung durch die weitverbreitete (und inkorrekte) Verwendung dieser Richtlinie zur Verhinderung von Caching ausgelöst wurde.

...

Beachten Sie, dass sich "cache-control: no-cache" in letzter Zeit ebenfalls wie die Direktive "no-store" verhält.

Abgesehen davon scheint es mir, dass Cache-Control: max-age=0, must-revalidate im Grunde dasselbe bedeuten sollte wie Cache-Control: no-cache. Vielleicht ist das eine Möglichkeit, das MUSS - Verhalten von no-cache erneut zu validieren, während die scheinbare Migration von no-cache vermieden wird, um dasselbe zu tun wie no-store (dh überhaupt kein Caching)?


Wenn vom Benutzeragenten gesendet

Ich glaube shahkalpeshs Antwort gilt für die User-Agent-Seite. Sie können sich auch 13.2.6 Mehrfachnennung von Antworten ansehen.

Wenn ein Benutzeragent eine Anfrage mit Cache-Control: max-age=0 (auch bekannt als "End-to-End-Revalidierung") sendet, wird jeder Cache auf dem Weg seinen Cache-Eintrag erneut validieren (z. B. mit dem Header If-Not-Modified) der Weg zum Origin-Server. Wenn die Antwort dann 304 (Nicht geändert) lautet, kann die zwischengespeicherte Entität verwendet werden.

Das Senden einer Anfrage mit Cache-Control: no-cache (auch bekannt als "End-to-End-Reload") wird hingegen nicht erneut validiert, und der Server DARF KEIN zwischengespeichertes verwenden Kopieren Sie, wenn Sie antworten.

569
Michael Krebs

maximales Alter =

Dies entspricht dem Klicken auf Aktualisieren. Geben Sie mir also die neueste Kopie, es sei denn, ich habe bereits die neueste Kopie.

kein Cache

Dies hält mschalttaste gedrückt, während Sie auf "Aktualisieren" klicken. Dies bedeutet, dass Sie einfach alles wiederholen, egal was passiert.

53
Gunnar Cheng

Alte Frage jetzt, aber wenn jemand durch eine Suche darauf stößt, wie ich es getan habe, wird IE9 dies anscheinend nutzen, um das Verhalten von Ressourcen zu konfigurieren, wenn die Schaltflächen Zurück und Vorwärts verwendet werden. Wenn max-age = 0 verwendet wird, verwendet der Browser die letzte Version, wenn eine Ressource bei einem Vorwärts-/Rückwärtsdruck angezeigt wird. Wenn kein Cache verwendet wird, wird die Ressource erneut abgerufen.

Weitere Informationen zum Zwischenspeichern von IE9 finden Sie in diesem msdn caching blog post .

34
El Yobo

In meinen letzten Tests mit IE8 und Firefox 3.5 scheinen beide RFC-kompatibel zu sein. Sie unterscheiden sich jedoch in ihrer "Freundlichkeit" zum Origin-Server. IE8 behandelt no-cache Antworten mit der gleichen Semantik wie max-age=0,must-revalidate. Firefox 3.5 scheint jedoch no-cache als äquivalent zu no-store zu behandeln, was der Leistung und der Bandbreitennutzung schadet.

Squid Cache scheint standardmäßig niemals etwas mit einem no-cache -Header zu speichern, genau wie Firefox.

Mein Rat wäre, public,max-age=0 für nicht sensible Ressourcen festzulegen, die bei jeder Anforderung auf Aktualität überprüft werden sollen, aber dennoch die Leistungs- und Bandbreitenvorteile des Cachings zuzulassen. Verwenden Sie private,max-age=0 für Elemente pro Benutzer mit derselben Überlegung.

Ich würde auf die Verwendung von no-cache gänzlich verzichten, da es von einigen Browsern und gängigen Caches als bastardiert angesehen wird, was dem funktionalen Äquivalent von no-store entspricht.

Emulieren Sie außerdem nicht Akamai und Limelight. Während sie im Wesentlichen massive Caching-Arrays als Hauptgeschäft betreiben und Experten sein sollten, haben sie tatsächlich ein berechtigtes Interesse daran, dass mehr Daten aus ihren Netzwerken heruntergeladen werden. Google ist möglicherweise auch keine gute Wahl für die Emulation. Sie scheinen max-age=0 oder no-cache je nach Ressource zufällig zu verwenden.

27
rmalayter
 max-age 
 Wenn ein Zwischen-Cache mittels einer max-age = 0-Direktive gezwungen wird, 
 seinen eigenen Cache-Eintrag erneut zu validieren, und der Client seinen eigenen bereitgestellt hat Validator in der Anfrage, der 
 angegebene Validator kann sich von dem Validator unterscheiden, der derzeit mit dem Cache-Eintrag gespeichert ist. 
 In diesem Fall KANN der Cache einen der Validatoren verwenden, um seine eigene Anfrage zu stellen, ohne 
 Die semantische Transparenz zu beeinträchtigen. 
 
 Die Wahl des Validators kann sich jedoch auf die Leistung auswirken. Am besten ist es, wenn der 
 Zwischen-Cache bei der Anforderung einen eigenen Validator verwendet. Wenn der Server 
 Mit 304 (Nicht geändert) antwortet, kann der Cache seine jetzt validierte Kopie mit einer Antwort von 200 (OK) an den Client 
 Zurückgeben. Wenn der Server mit einer neuen Entität und einem neuen Cache-Validator antwortet, 
 Kann der Zwischen-Cache den zurückgegebenen Validator jedoch mit dem in 
 Der Client-Anfrage bereitgestellten Validator unter Verwendung der starken Vergleichsfunktion vergleichen. Wenn der Validator des Clients 
 Dem des Origin-Servers entspricht, gibt der Zwischen-Cache einfach 304 (Not 
 Modified) zurück. Andernfalls wird die neue Entität mit einer Antwort von 200 (OK) zurückgegeben. 

 Wenn eine Anfrage die No-Cache-Direktive enthält, DARF sie NICHT min-fresh, 
 Max-stale oder max-age enthalten. 

mit freundlicher Genehmigung von: http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.4

Akzeptiere dies nicht als Antwort - ich muss es lesen, um die wahre Verwendung zu verstehen :)

20
shahkalpesh

Übrigens ist es erwähnenswert, dass einige mobile Geräte, insbesondere Apple Produkte wie iPhone/iPad, Header wie no-cache, no-store, Expires: 0 oder was auch immer Sie versuchen, sie zu erzwingen, vollständig ignorieren abgelaufene Formularseiten nicht wiederverwenden.

Dies hat uns Kopfschmerzen bereitet, da wir versuchen, das Problem des iPads eines Benutzers zu lösen, indem wir auf einer Seite, die sie durch einen Formularprozess erreicht haben, schlafen gehen, sagen wir Schritt 2 von 3, und das Gerät ignoriert dann den Speicher/Cache-Direktiven, und soweit ich das beurteilen kann, erstellen einfach einen virtuellen Schnappschuss der Seite aus ihrem letzten Zustand, dh ignorieren, was explizit angegeben wurde, und nicht nur das, sondern eine Seite, die nicht gespeichert werden sollte , und speichern, ohne es erneut zu überprüfen, was unter anderem zu allerlei seltsamen Sitzungsproblemen führt.

Ich füge dies nur für den Fall hinzu, dass jemand vorbeikommt und nicht herausfinden kann, warum Sitzungsfehler bei bestimmten iPhones und iPads auftreten, die bei weitem die schlimmsten Straftäter in diesem Bereich zu sein scheinen.

Ich habe ziemlich umfangreiche Debugger-Tests mit diesem Problem durchgeführt, und dies ist meine Schlussfolgerung, dass die Geräte diese Anweisungen vollständig ignorieren.

Selbst bei regelmäßiger Verwendung habe ich festgestellt, dass einige Mobiltelefone auch nicht nach neuen Versionen suchen können, z.

Es passiert einfach nicht, also musste ich den CSS/JS-Dateien, die ich zum Erzwingen von Updates benötigte, Abfragezeichenfolgen hinzufügen, was die dummen Mobilgeräte dazu verleitet, zu glauben, dass es sich um eine Datei handelt, die es nicht gibt, wie z .css? v = 1, dann v = 2 für ein CSS/JS-Update. Das funktioniert weitgehend.

Übrigens: Benutzer-Browser können ab 2016, wie ich laufend feststelle (wir nehmen VIELE Änderungen und Aktualisierungen an unserer Website vor), auch nicht nach den letzten Änderungsdaten für solche Dateien suchen, sondern nur nach der Abfrage String-Methode behebt das Problem. Dies ist etwas, das ich bei Kunden und Büromitarbeitern bemerkt habe, die dazu neigen, normale Benutzervorgaben in ihren Browsern zu verwenden, und keine Kenntnis von Caching-Problemen mit CSS/JS usw. haben und es fast immer nicht schaffen, die neuen CSS/JS zu ändern. Dies bedeutet, dass die Standardeinstellungen für ihre Browser, meistens MSIE/Firefox, nicht den Anweisungen entsprechen, Änderungen ignorieren und die letzten Änderungsdaten ignorieren und nicht validieren, auch wenn Expires: 0 explizit festgelegt ist.

Dies war ein guter Thread mit vielen guten technischen Informationen, aber es ist auch wichtig zu bemerken, wie schlecht die Unterstützung für dieses Zeug in besonders mobilen Geräten ist. Alle paar Monate muss ich weitere Schutzschichten hinzufügen, um zu verhindern, dass sie den empfangenen Header-Befehlen nicht folgen oder diese Befehle richtig interpretieren.

12
Lizardx

Ich bin kaum ein Caching-Experte, aber Mark Nottingham ist es. Hier sind seine Caching-Dokumente . Er hat auch hervorragende Links im Bereich Referenzen.

Aufgrund meiner Lektüre dieser Dokumente sieht es so aus, als ob max-age=0 es dem Cache ermöglichen könnte, eine zwischengespeicherte Antwort auf Anforderungen zu senden, die zur "gleichen Zeit" eingegangen sind, wobei "zur gleichen Zeit" bedeutet, dass sie nah genug beieinander liegen und gleichzeitig aussehen Cache, aber no-cache würde nicht.

12
Hank Gay

Ich schreibe eine Reihe von Artikeln, die sich eingehend mit diesen Themen befassen und die meiner Meinung nach unter Entwicklern nicht genug diskutiert wurden.

Browser, private Proxys und CDNs:
https://medium.com/free-code-camp/http-caching-in-depth-part-1-a853c6af99db

Cache-Control & Varyhttps://medium.com/@lojacquemin/an-in-depth-introduction-to-http-caching-cache-control-vary-e3229815ddf4

0
Radioreve

Der Unterschied besteht darin, dass kein Cache (no-store in Firefox) jede Art von Caching verhindert. Dies kann nützlich sein, um zu verhindern, dass Seiten mit sicherem Inhalt auf die Festplatte geschrieben werden, und für Seiten, die immer aktualisiert werden sollten, selbst wenn sie mit der Schaltfläche "Zurück" erneut aufgerufen werden.

max-age = 0 gibt an, dass ein Cache-Eintrag veraltet ist und eine erneute Überprüfung erfordert, verhindert jedoch nicht das Zwischenspeichern. Häufig validieren Browser Ressourcen nur einmal pro Browsersitzung, sodass der Inhalt möglicherweise erst aktualisiert wird, wenn die Site in einer neuen Sitzung besucht wird.

Normalerweise löschen Browser abgelaufene Cache-Einträge nicht, es sei denn, sie beanspruchen den Speicherplatz für neuere Inhalte zurück, wenn der Browser-Cache voll ist. Bei Verwendung von no-store, no-cache kann ein Cache-Eintrag explizit gelöscht werden.

0