wake-up-neo.com

"Cache-Control: max-age = 0, kein Cache", aber Browser umgeht die Serverabfrage (und trifft den Cache).

Ich benutze Chrome 40 (also etwas Schönes und Modernes).

Cache-Control: max-age=0, no-cache ist auf allen Seiten festgelegt - daher erwarte ich, dass der Browser nur dann etwas aus seinem Cache verwendet, wenn er zuvor mit dem Server eine Überprüfung durchgeführt hat und eine 304 Not Modified-Antwort erhalten hat.

Beim Drücken der Zurück-Taste stößt der Browser jedoch fröhlich in den eigenen Cache, ohne den Server zu überprüfen.

Wenn ich dieselbe Seite öffne, habe ich, wie ich mit dem Zurück-Button erreicht habe, in einem neuen Tab den Server überprüft (und bekommt eine 303 See Other-Antwort, wenn sich die Dinge geändert haben).

In der Abbildung unten finden Sie die Ausgabe für die zwei verschiedenen Fälle auf der Registerkarte "Netzwerk" der Chrome Developer Tools.

Ich dachte, ich könnte max-age=0, no-cache als eine leichtere Alternative zu no-store verwenden, wenn Benutzer nicht möchten, dass veraltete Daten über die Zurück-Schaltfläche angezeigt werden (aber wo die Daten nicht wertvoll sind und daher zwischengespeichert werden können).

Ich verstehe no-cache (siehe hier und hier über SO): Der Browser muss alle Antworten immer erneut überprüfen. Warum tut Chrome dies nicht, wenn Sie die Zurück-Taste verwenden?

Ist no-store die einzige Option?


200 Antwort (vom Cache) auf die Zurück-Taste:

enter image description here

303 antwort, wenn dieselbe Seite in einem neuen Tab angefordert wird:

enter image description here

13
George Hawkins

Von http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.1

kein Cache

Wenn in der Direktive no-cache kein Feldname angegeben ist, darf ein Cache die Antwort NICHT verwenden, um eine nachfolgende Anforderung zu erfüllen, ohne dass eine erneute Validierung beim Origin-Server erfolgreich war. Auf diese Weise kann ein Origin-Server die Zwischenspeicherung auch von Caches verhindern, die so konfiguriert sind, dass veraltete Antworten auf Clientanforderungen zurückgegeben werden. 

Wenn die Direktive ohne Cache einen oder mehrere Feldnamen angibt, KANN ein Cache möglicherweise die Antwort verwenden, um eine nachfolgende Anforderung zu erfüllen, vorbehaltlich anderer Einschränkungen beim Zwischenspeichern. Die angegebenen Feldnamen MÜSSEN jedoch NICHT in der Antwort auf eine nachfolgende Anforderung gesendet werden, ohne dass eine erneute Validierung mit dem Origin-Server durchgeführt wurde. Auf diese Weise kann ein Origin-Server die Wiederverwendung bestimmter Header-Felder in einer Antwort verhindern, während der Rest der Antwort weiterhin zwischengespeichert werden kann.

Anders als der Name impliziert, erfordert no-cache nicht, dass die Antwort nicht im Cache gespeichert werden darf. Es gibt lediglich an, dass die zwischengespeicherte Antwort nicht erneut für eine following - Anforderung verwendet werden darf, ohne dass eine erneute Validierung erfolgt. Daher ist dies eine Abkürzung für must-revalidate, max-age=0.

Es ist Sache des Browsers, was als following -Anforderung zu qualifizieren ist, und meines Wissens unter Verwendung des Zurück-Buttons nicht. Dieses Verhalten variiert zwischen verschiedenen Browser-Engines.

no-store verbietet die Verwendung der zwischengespeicherten Antwort für alle Anforderungen, nicht nur für nachfolgende.

Beachten Sie, dass der RFC selbst mit no-store dem Client tatsächlich erlaubt, die Antwort zur Verwendung in Verlaufspuffern zu speichern. Das bedeutet, dass der Client auch dann eine zwischengespeicherte Antwort verwenden kann, wenn no-store angegeben wurde.

Letzteres Verhalten deckt Fälle ab, in denen die Seite mit ihrem ursprünglichen Seitentitel im Browserverlauf aufgezeichnet wurde. Ein weiterer Anwendungsfall ist das Verhalten verschiedener mobiler Browser, bei dem die vorherige Seite erst verworfen wird, wenn die folgende Seite vollständig geladen ist, da der Benutzer den Vorgang möglicherweise abbrechen möchte.

Zur Verdeutlichung des Verhaltens der Zurück-Schaltfläche: Gemäß http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.13 unterliegt kein Cache-Header.

Benutzeragenten verfügen häufig über Verlaufsmechanismen, wie z. B. "Zurück" -Schaltflächen und Verlaufslisten, mit denen eine zuvor in einer Sitzung abgerufene Entität erneut angezeigt werden kann.

Historienmechanismen und Caches sind unterschiedlich. In bestimmten Historienmechanismen sollte NICHT versucht werden, eine semantisch transparente Ansicht des aktuellen Status einer Ressource zu zeigen. Ein Verlaufsmechanismus soll vielmehr zeigen, was der Benutzer zu dem Zeitpunkt gesehen hat, als die Ressource abgerufen wurde.

Standardmäßig gilt eine Ablaufzeit nicht für Protokollmechanismen. Wenn sich die Entität noch im Speicher befindet, SOLLTE ein Verlaufsmechanismus ihn anzeigen, auch wenn die Entität abgelaufen ist, es sei denn, der Benutzer hat den Agenten speziell für die Aktualisierung abgelaufener Historiendokumente konfiguriert.

Das bedeutet, dass das Nichtbeachten der Cache-Steuerungsheader bei Verwendung der Zurück-Schaltfläche das empfohlene Verhalten ist. Wenn Ihr Browser ein veraltetes Verfallsdatum einhält oder die no-store-Direktive nicht nur auf den Cache des Browsers, sondern auch auf den Verlauf anwendet, weicht dies bereits von dieser Empfehlung ab.

Um es zu lösen:
.__ Sie können nicht, und Sie dürfen nicht. Wenn der Benutzer zu einer zuvor besuchten Seite zurückkehrt, versuchen die meisten Browser sogar, das Ansichtsfenster wiederherzustellen. Sie können einen verzögerten Mechanismus wie AJAX verwenden, um Inhalte zu aktualisieren, wenn dies das ursprüngliche Verhalten war, bevor der Benutzer die Seite verlassen hat. Andernfalls sollten Sie den Inhalt nicht ändern.

23
Ext3h

Haben Sie versucht, den vollständigen alten Satz von No-Cache-Headern zu verwenden?

<meta http-equiv="cache-control" content="max-age=0" />
<meta http-equiv="cache-control" content="no-cache" />
<meta http-equiv="expires" content="0" />
<meta http-equiv="expires" content="Tue, 01 Jan 1980 1:00:00 GMT" />
<meta http-equiv="pragma" content="no-cache" />

Dies scheint die ganze Zeit zu funktionieren, es sei denn, Sie betreiben ein "pushState" - Web.

1
Ingmars

Es sieht so aus, als sei dies in Chrome mit dem Zurück-Button bekannt. Es gibt eine gute Diskussion über das Problem im Fehlerbericht. Hier:

https://code.google.com/p/chromium/issues/detail?id=28035

Leider sieht es so aus, als würden die meisten Leute stattdessen No-Store verwenden.

Ich erwarte jedoch, dass die meisten Benutzer daran gewöhnt sind, keine vollständige Seitenaktualisierung mithilfe der Zurück-Schaltfläche zu erhalten. Wenn Sie über die meisten Angular - oder Backbone-Apps nachdenken, die die Back-Action selbst verwalten, können Sie nur den Inhalt und nicht die Seite aktualisieren. In diesem Sinne vermute ich, dass es nicht so unerwartet ist, dass der Kunde bei seiner Rückkehr aktualisiert oder aktualisiert wird.

1
JodiMiddleton