wake-up-neo.net

Warum sollten No-Cache und No-Store in der HTTP-Antwort verwendet werden?

Mir wird gesagt, dass Benutzerinformationen nicht auslaufen sollten, nur "No-Cache" als Antwort reicht nicht aus. "no-store" ist ebenfalls notwendig.

Cache-Control: no-cache, no-store

Nach dem Lesen dieser Spezifikation http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html bin ich immer noch nicht ganz sicher, warum.

Mein aktuelles Verständnis ist, dass es nur für Zwischen-Cache-Server ist. Auch wenn "no-cache" als Antwort ausgeführt wird, kann der Zwischenspeicherserver den Inhalt trotzdem in einem nichtflüchtigen Speicher speichern. Der Zwischen-Cache-Server entscheidet, ob der gespeicherte Inhalt für die nachfolgende Anforderung verwendet wird. Wenn jedoch in der Antwort "no-store" enthalten ist, soll der Zwischenspeicherserver den Inhalt nicht speichern. Also ist es sicherer.

Gibt es einen anderen Grund, warum wir "no-cache" und "no-store" benötigen?

110
Morgan Cheng

Ich muss klarstellen, dass no-cache nicht bedeutet cache nicht. Tatsächlich bedeutet dies "erneute Validierung beim Server", bevor Sie bei jeder Anforderung eine zwischengespeicherte Antwort verwenden.

Andererseits muss must-revalidate nur erneut validiert werden, wenn die Ressource als veraltet gilt.

Wenn der Server angibt, dass die Ressource noch gültig ist, kann der Cache mit seiner Darstellung antworten, sodass der Server die gesamte Ressource nicht erneut senden muss.

no-store ist praktisch die vollständige cache - Direktive und soll das Speichern der Repräsentation in jeglicher Form von Cache verhindern.

Ich sage was auch immer, aber beachte dies in der RFC 2616-HTTP-Spezifikation:

Verlaufspuffer KÖNNEN solche Antworten möglicherweise als Teil ihres normalen Betriebs speichern

Dies wird jedoch aus der neueren RFC 7234-HTTP-Spezifikation ausgelassen, um möglicherweise no-store stärker zu machen, siehe:

http://tools.ietf.org/html/rfc7234#section-5.2.1.5

67
Luke Puplett

Unter bestimmten Umständen speichert der IE6 die Dateien auch dann, wenn sich Cache-Control: no-cache in den Antwortheadern befindet.

Die W3C-Zustände von no-cache :

Wenn die No-Cache-Direktive nicht Geben Sie einen Feldnamen und dann einen Cache an MUSS NICHT die Antwort verwenden, um eine .__ zu erfüllen. nachfolgende Anfrage ohne erfolgreichen Überprüfung mit dem Origin-Server.

Wenn Sie in meiner Anwendung eine Seite mit dem no-cache-Header besucht haben, sich abgemeldet und dann in Ihrem Browser zurückgeschlagen haben, ruft der IE6 die Seite trotzdem aus dem Cache (ohne eine neue/validierende Anforderung an den Server). Durch das Hinzufügen im no-store-Header wurde dies beendet. Aber wenn Sie den W3C an ihrem Wort nehmen, gibt es eigentlich keine Möglichkeit, dieses Verhalten zu kontrollieren:

Verlaufspuffer KÖNNEN solche Antworten möglicherweise als Teil ihres normalen Betriebs speichern.

Allgemeine Unterschiede zwischen dem Browserverlauf und dem normalen HTTP-Caching werden beschrieben in einem bestimmten Unterabschnitt der Spezifikation .

43
Alconja

Aus der HTTP 1.1-Spezifikation :

no-store:

Der Zweck der Direktive no-store besteht darin, die versehentliche Veröffentlichung oder Aufbewahrung vertraulicher Informationen (z. B. auf Sicherungsbändern) zu verhindern. Die Direktive No-Store gilt für die gesamte Nachricht und kann entweder in einer Antwort oder in einer Anfrage gesendet werden. Wenn der Cache in einer Anfrage gesendet wird, darf er weder einen Teil dieser Anfrage noch eine Antwort darauf speichern. Wenn der Cache in einer Antwort gesendet wird, darf er weder einen Teil dieser Antwort noch die Anforderung, die sie ausgelöst hat, speichern. Diese Anweisung gilt sowohl für nicht gemeinsam genutzte als auch für gemeinsam genutzte Caches. "MUSS NICHT gespeichert werden" bedeutet in diesem Zusammenhang, dass der Cache die Informationen NICHT absichtlich in einem nichtflüchtigen Speicher ablegen MUSS und unbedingt versuchen muss, die Informationen aus dem flüchtigen Speicher nach der Weiterleitung so schnell wie möglich zu entfernen . Selbst wenn diese Anweisung mit einer Antwort verknüpft ist, können Benutzer eine solche Antwort explizit außerhalb des Zwischenspeichersystems speichern (z. B. mit einem "Speichern unter" -Dialogfeld). Historienpuffer KÖNNEN solche Antworten möglicherweise als Teil ihres normalen Betriebs speichern. Der Zweck dieser Richtlinie besteht darin, die angegebenen Anforderungen bestimmter Benutzer und Dienstautoren zu erfüllen, die durch unvorhergesehene Zugriffe auf Informationen zur Zwischenspeicherung von Datenstrukturen besorgt sind. Die Verwendung dieser Richtlinie kann zwar die Privatsphäre in einigen Fällen verbessern, wir weisen jedoch darauf hin, dass sie KEINE zuverlässigen oder ausreichenden Mechanismen zur Gewährleistung der Privatsphäre darstellt. Insbesondere können böswillige oder kompromittierte Caches diese Direktive nicht erkennen oder befolgen, und Kommunikationsnetzwerke können anfällig für das Abhören sein.

16
backslash17

Wenn Sie alle Zwischenspeicherungen verhindern möchten (z. B. bei Verwendung der Zurück-Taste ein Neuladen erzwingen), benötigen Sie Folgendes:

  • kein Cache für IE

  • no-Store für Firefox

Hier gibt es meine Informationen dazu:

http://blog.httpwatch.com/2008/10/15/zwei-wichtige-differenzen-zwischen-firefox-und-ie-caching/

12

no-store sollte in normalen Situationen nicht erforderlich sein und kann sowohl die Geschwindigkeit als auch die Benutzerfreundlichkeit beeinträchtigen. Es ist für den Gebrauch vorgesehen, bei dem die HTTP-Antwort Informationen enthält, die so sensibel sind, dass sie niemals in einen Plattencache geschrieben werden sollten, unabhängig von den negativen Auswirkungen, die für den Benutzer entstehen.

Wie es funktioniert:

  • Selbst wenn ein Benutzeragent wie ein Browser feststellt, dass eine Antwort nicht zwischengespeichert werden soll, speichert er sie normalerweise aus internen Gründen im Festplattencache. Diese Version kann für Funktionen wie "Quelltext anzeigen", "Zurück", "Seiteninfo" usw. verwendet werden, bei denen der Benutzer die Seite nicht unbedingt erneut angefordert hat, der Browser sie jedoch nicht als neue Seitenansicht betrachtet und es wäre sinnvoll, dieselbe Version zu verwenden, die der Benutzer gerade anzeigt.

  • Die Verwendung von no-store verhindert, dass diese Antwort gespeichert wird. Dies kann jedoch die Fähigkeit des Browsers beeinträchtigen, "Quelle anzeigen", "Zurück", "Seiteninfo" usw. anzuzeigen, ohne eine neue separate Anforderung an den Server zu stellen, was unerwünscht ist. Mit anderen Worten, der Benutzer kann versuchen, die Quelle anzuzeigen, und wenn der Browser sie nicht im Speicher aufbewahrt, wird ihm entweder mitgeteilt, dass dies nicht möglich ist, oder es wird eine neue Anfrage an den Server verursacht. Daher sollte no-store nur verwendet werden, wenn die behinderte Benutzererfahrung, dass diese Funktionen nicht ordnungsgemäß funktionieren oder schnell ausgeführt werden, durch die Wichtigkeit der Sicherstellung, dass Inhalte nicht im Cache gespeichert werden, aufgewogen wird.

Mein aktuelles Verständnis ist, dass es nur für Zwischen-Cache-Server ist. Auch wenn "no-cache" als Antwort ausgeführt wird, kann der Zwischenspeicherserver den Inhalt trotzdem in einem nichtflüchtigen Speicher speichern.

Das ist falsch. Mit HTTP 1.1 kompatible Zwischen-Cache-Server befolgen die Anweisungen no-cache und must-revalidate, um sicherzustellen, dass der Inhalt nicht zwischengespeichert wird. Durch die Verwendung dieser Anweisungen wird sichergestellt, dass die Antwort nicht von einem Zwischencache zwischengespeichert wird und alle nachfolgenden Anforderungen an den Origin-Server zurückgesendet werden.

Wenn der Zwischen-Cache-Server HTTP 1.1 nicht unterstützt, müssen Sie Pragma: no-cache verwenden und auf das Beste hoffen. Beachten Sie, dass no-store ohnehin irrelevant ist, wenn HTTP 1.1 nicht unterstützt wird.

11
thomasrutter

Wenn ein Caching-System No-Store korrekt implementiert, benötigen Sie No-Cache nicht. Aber nicht alle tun es. Darüber hinaus implementieren einige Browser No-Cache, als wäre es kein Speicher. Obwohl dies nicht unbedingt erforderlich ist, ist es wahrscheinlich am sichersten, beide zu berücksichtigen.

7
james.garriss

Bei Chrome wird No-Cache verwendet, um die Seite bei einem erneuten Besuch neu zu laden. Zwischenspeicherung erfolgt jedoch, wenn Sie in der Verlaufsliste zurückgehen (Schaltfläche "Zurück"). Verwenden Sie No-Store, um die Seite auch für den Verlauf zurück zu laden. IE muss in allen Fällen funktionieren.

Nur um sicherzugehen, dass ich alle Fehler und Fehlinterpretationen, die ich immer benutze, vermeiden

Cache-Control: no-store, no-cache, must-revalidate

wenn ich sichergehen will, dass es neu geladen wird.

7
woens

Beachten Sie, dass der Internet Explorer von Version 5 bis 8 einen Fehler ausgibt, wenn versucht wird, eine über https bereitgestellte Datei herunterzuladen und der Server Cache-Control: no-cache oder Pragma: no-cache-Header sendet.

Siehe http://support.Microsoft.com/kb/812935/en-us

Die Verwendung von Cache-Control: no-store und Pragma: private scheint die nächste Sache zu sein, die noch funktioniert.

6
bassim

Ursprünglich verwendeten wir No-Cache vor vielen Jahren und hatten bei einigen Browsern einige Probleme mit veralteten Inhalten ... Ich erinnere mich nicht an die Besonderheiten.

Wir hatten uns seitdem auf NUR entschieden, No-Store zu verwenden. Habe noch nie zurückgesehen oder hatte ein Problem mit veralteten Inhalten seitens eines Browsers oder Vermittlers.

Dieser Raum wird sicherlich von der Realisierungsrealität dominiert, was in verschiedenen RFCs geschrieben wurde. Insbesondere viele Stellvertreter neigen zu der Ansicht, dass sie die Leistung besser verbessern, indem sie die Politik ersetzen, die sie durch ihre eigene Politik ersetzen sollten.

2
Einstein

Nur um das Ganze noch schlimmer zu machen, kann No-Cache in manchen Situationen nicht verwendet werden, No-Store jedoch:

http://faindu.wordpress.com/2008/04/18/ie7-ssl-xml-flex-error-2032-stream-error/

1
Jamie Love

OWASP diskutiert dies:

Was ist der Unterschied zwischen den Anweisungen zur Cache-Steuerung: No-Cache und No-Store?

Die No-Cache-Direktive in einer Antwort gibt an, dass die Antwort nicht für eine nachfolgende Anforderung verwendet werden darf, d. H. Der Cache darf keine Antwort anzeigen, in der diese Direktive im Header festgelegt ist, der Server muss jedoch die Anforderung bedienen. Die Direktive ohne Cache kann einige Feldnamen enthalten. In diesem Fall kann die Antwort aus dem Cache angezeigt werden, mit Ausnahme der angegebenen Feldnamen, die vom Server bereitgestellt werden sollen. Die Direktive no-store gilt für die gesamte Nachricht und gibt an, dass der Cache keinen Teil der Antwort oder Anforderung, die danach gefragt wurde, speichern darf.

Bin ich mit diesen Richtlinien absolut sicher?

Verwenden Sie im Allgemeinen jedoch sowohl Cache-Control: No-Cache, No-Store als auch Pragma: No-Cache, zusätzlich zu Expires: 0 (oder ein ausreichend zurückgesetztes GMT-Datum wie die UNIX-Epoche). Nicht-HTML-Inhaltstypen wie PDF, Word-Dokumente, Excel-Tabellen usw. werden häufig zwischengespeichert, selbst wenn die obigen Cache-Steueranweisungen festgelegt sind (dies hängt jedoch von Version und zusätzlicher Verwendung von must-revalidate ab, pre-check = 0, post-check) = 0, max-age = 0 und s-maxage = 0 kann in der Praxis manchmal dazu führen, dass Dateien beim Schließen des Browsers gelöscht werden (in einigen Fällen aufgrund von Browser-Macken und HTTP-Implementierungen). Mit der Funktion "Autocomplete" kann ein Browser zwischenspeichern, was der Benutzer in ein Eingabefeld eines Formulars eingibt. Um dies zu überprüfen, sollte das Formular-Tag oder die einzelnen Eingabe-Tags das Attribut "Autocomplete =" Off "enthalten. Es sollte jedoch beachtet werden, dass dieses Attribut nicht standardmässig ist (obwohl es von den wichtigsten Browsern unterstützt wird), so dass die XHTML-Validierung durchbrochen wird.

Quelle hier .

0
Jan Żankowski