Warum beide no-cache und no-store sollten in HTTP-Antwort verwendet werden?

Question

mir gesagt user-info undicht, nur „no-cache“ als Reaktion zu verhindern, ist nicht genug. "No-store" ist auch notwendig.

Cache-Control: no-cache, no-store

Nach dieser Spezifikation lesen http://www.w3.org/Protocols/ RFC2616 / RFC2616-sec14.html , ich bin noch nicht ganz sicher, warum.

Ihr gegenwärtiges Verständnis ist, dass es nur für Zwischen Cache-Server ist. Auch wenn „no-cache“ in Antwort ist, können Zwischen Cache-Server noch den Inhalt zu nicht-flüchtigen Speicher speichern. Der Zwischen Cache-Server wird darüber entscheiden, ob die gespeicherte Inhalte für folgende Anfrage mit. Wenn jedoch „no-store“ in der Antwort ist, wird der Zwischen Cache Sever eigentlich nicht um den Inhalt zu speichern. So ist es sicherer zu machen.

Gibt es einen anderen Grund, warum wir brauchen beide "no-cache" und "no-store"?

Answer 1

Ich muss klarstellen, dass no-cache bedeutet nicht, Sie cachen nicht . In der Tat bedeutet es „mit Server revalidate“, bevor sie eine zwischengespeicherte Antwort verwenden Sie bei jeder Anfrage haben, können.

must-revalidate, auf der anderen Seite muss nur revalidate, wenn die Ressource abgestanden angesehen wird.

Wenn der Server sagt, dass die Ressource nach wie vor gültig ist, dann kann der Cache mit seiner Darstellung reagieren, wodurch die Notwendigkeit für den Server Linderung der gesamte Ressource erneut zu senden.

no-store ist effektiv die volle Sie cachen nicht Richtlinie und sollte auch immer Speicherung der Darstellung in irgendeiner Form von Cache verhindern.

Ich sage auch immer, aber beachten Sie, das im RFC 2616 HTTP-Spezifikation:

  

Geschichte Puffer speichern können solche Reaktionen als Teil ihres normalen Betriebes

Aber das ist aus der neueren RFC 7234 HTTP-Spezifikation in möglicherweise einen Versuch weggelassen zu machen no-store stärker finden Sie unter:

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

Answer 2

Unter bestimmten Umständen IE6 noch Cache-Dateien, auch wenn Cache-Control: no-cache in der Antwort-Header ist.

Die W3C Staaten von no-cache :

  

Wenn der no-cache Direktive nicht   Geben Sie einen Feldnamen, dann eine Cache   Darf nicht die Antwort verwenden eine befriedigen   nachfolgende Anforderung ohne Erfolg   Revalidierung mit dem Ursprungsserver.

In meiner Anwendung, wenn Sie eine Seite mit dem no-cache Header besucht, protokolliert dann aus und drücken Sie dann in Ihrem Browser zurück, IE6 würde immer noch die Seite aus dem Cache greifen (ohne eine neue / Validierung Anfrage an den Server). Hinzufügen in dem no-store Kopf gestoppt es so zu tun. Aber wenn Sie das W3C beim Wort nehmen, gibt es eigentlich keine Möglichkeit, dieses Verhalten zu steuern:

  

Geschichte Puffer speichern kann solche Reaktionen als Teil ihrer normalen Betrieb zurück.

Allgemeine Unterschiede zwischen Browser-History und dem normalen HTTP-Caching beschrieben in einem bestimmten Teilbereich des spec .

Answer 3

Aus dem HTTP 1.1-Spezifikation :

  

no-store :

     

Der Zweck der no-store Richtlinie ist die unbeabsichtigte Freisetzung oder Speicherung von sensiblen Informationen (zum Beispiel auf Backup-Bändern) zu verhindern. Die no-store-Richtlinie gilt für die gesamte Nachricht und kann entweder in einer Antwort oder in einer Anfrage gesendet werden. Wenn in einer Anforderung gesendet wird, muss ein Cache speichert keinen Teil entweder diese Anfrage oder eine Antwort darauf. Wenn in einer Antwort gesendet, muss ein Cache speichert keinen Teil entweder diese Antwort oder die Anforderung, die es ausgelöst. Diese Richtlinie gilt für beide nicht Caches geteilt und gemeinsam genutzt. „Nicht speichern“ in diesem Zusammenhang bedeutet, dass der Cache nicht absichtlich die Informationen in nichtflüchtigen Speichern gespeichert werden muss, und muss einen Best-Effort-Versuch machen, die Informationen aus flüchtigen Speichern so schnell wie möglich zu entfernen, nachdem sie weiterzuleiten.   Auch wenn diese Richtlinie mit einer Antwort verknüpft ist, können Benutzer explizit speichern, eine solche Antwort außerhalb des Caching-System (beispielsweise mit einem „Speichern unter“ Dialog). Geschichte Puffer speichern kann solche Reaktionen als Teil ihres normalen Betriebs.   Der Zweck dieser Richtlinie ist es, die genannten Anforderungen bestimmten Benutzers und Service-Autoren zu treffen, die über unerwartete Zugriffe über die unbeabsichtigte Freisetzung von Informationen betroffen sind, um Datenstrukturen zwischenspeichern. Während die Verwendung dieser Richtlinie Privatsphäre in einigen Fällen verbessern könnten, warnen wir, dass es für die Gewährleistung der Privatsphäre in keiner Weise ein zuverlässiger oder ausreichend Mechanismus ist. Insbesondere können nicht erkennen oder diese Anweisung schädliche oder manipulierten Caches gehorchen und Kommunikationsnetze könnten Abhören anfällig sein.

Answer 4

Wenn Sie wollen, dass alle Caching verhindern (zum Beispiel eines erneuten Laden erzwingen, wenn die Rücktaste) benötigen Sie:

• no-cache für IE

• no-store für Firefox

Es ist meine Informationen über diese hier:

http: / /blog.httpwatch.com/2008/10/15/two-important-differences-between-firefox-and-ie-caching/

Answer 5

no-store sollte unter normalen Umständen nicht notwendig sein, und sowohl die Geschwindigkeit und Benutzerfreundlichkeit schaden kann. Es ist für die Verwendung in dem die HTTP-Antwort enthält Informationen so empfindlich, soll es nie zu einem Festplatte-Cache geschrieben werden, unabhängig von den negativen Auswirkungen, die für den Benutzer erstellt.

Wie es funktioniert:

• Normalerweise, auch wenn ein User-Agent wie ein Browser feststellt, dass eine Antwort nicht zwischengespeichert werden soll, kann es speichern, noch es zu der Disk-Cache aus Gründen innerhalb des User-Agenten. Diese Version kann für Funktionen wie „Quelltext anzeigen“, „zurück“, „Seite info“, und so weiter verwendet werden, wo der Benutzer wieder nicht unbedingt die gewünschten Seite, aber der Browser hält es nicht für eine neue Seite Ansicht und es wäre sinnvoll, die gleiche Version der Benutzer zu dienen, schaut sich gerade.

• no-store Verwendung wird diese Reaktion verhindert gespeichert werden, aber dies kann die Browser-Fähigkeit auswirken „Quelltext anzeigen“ zu geben, „zurück“, „Seite info“ und so weiter, ohne eine neue, separate Anforderung für den Server zu machen , was unerwünscht ist. Mit anderen Worten, versuchen kann der Benutzer die Quelle sehen und wenn der Browser es nicht hielt im Speicher, werden sie entweder gesagt werden, dies nicht möglich ist, oder es wird eine neue Anfrage an den Server verursachen. Daher sollte no-store nur verwendet werden, wenn die behinderte Benutzer Erfahrung dieser Funktionen nicht richtig oder schnell arbeitet von der Bedeutung aufgewogen Inhalte sicherzustellen, wird nicht im Cache gespeichert.

  

Ihr gegenwärtiges Verständnis ist, dass es nur für Zwischen Cache-Server ist. Auch wenn „no-cache“ in Antwort ist, kann Zwischen Cache-Server noch den Inhalt zu nichtflüchtigen Speichern gespeichert werden.

Das ist falsch. Zwischen Cache-Servern kompatibel mit HTTP 1.1 wird die no-cache und must-revalidate Anweisungen befolgen, dass der Inhalt sichergestellt werden nicht zwischengespeichert. Mit diesen Anweisungen wird sichergestellt, dass die Antwort nicht von einem Zwischen Cache zwischengespeichert wird, und dass alle nachfolgenden Anforderungen zurück an den Ursprungsserver gesendet.

Wenn der Zwischen Cache-Server nicht HTTP unterstützt 1.1, dann müssen Sie Pragma: no-cache nutzen und das Beste zu hoffen. Beachten Sie, dass, wenn es nicht HTTP unterstützt 1.1 dann ist no-store irrelevant sowieso.

Answer 6

Wenn ein Caching-System korrekt No-Speicher implementiert, dann würden Sie no-cache nicht benötigen. Aber nicht alle tun. Darüber hinaus implementieren einige Browser no-cache wie es no-store war. Während also nicht unbedingt erforderlich, ist es wahrscheinlich sicherste beide enthalten.

Answer 7

Für Chrom wird no-cache verwendet, um die Seite auf einem erneuten Besuch neu zu laden, aber es speichert es nach wie vor, wenn Sie in der Geschichte zurückgehen (Zurück-Taste). Um die Seite für Geschichte zurück nachladen und verwenden keinen Laden. IE muss must-revalidate in alle Gelegenheiten zu arbeiten.

Also nur um sicher alle Fehler und Fehlinterpretationen zu vermeiden, verwende ich

immer

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

, wenn ich sicherstellen möchten, es neu geladen.

Answer 8

Hinweis

, dass Internet Explorer ab Version 5 bis 8 wird einen Fehler werfen, wenn eine Datei bedient über https zum Download versuchen, und der Server sendet Cache-Control: no-cache oder Pragma: no-cache Header.

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.

Answer 9

Ursprünglich haben wir No-Cache vor vielen Jahren und hat in einige Probleme mit veralteten Inhalte mit bestimmten Browsern laufen ... Sie die Einzelheiten nicht erinnern, leider.

Wir hatten seit siedelten nur auf die Verwendung von nicht-Store. Habe noch nie sah von jedem Browser oder Vermittler eine einzelne Ausgabe mit veraltetem Inhalt zurück oder hatte da.

Dieser Raum wird sicherlich von der Realität von Implementierungen vs dominiert, was passiert, in verschiedenen RFCs geschrieben wurde. Viele Proxies insbesondere neigen zu denken, dass sie eine bessere Arbeit der „Verbesserung der Leistung“ tun, indem sie die Politik ersetzen sie sollen mit ihren eigenen folgenden werden.

Answer 10

Nur um die Sache noch schlimmer, in manchen Situationen kann keine-Cache nicht verwendet werden, aber no-store kann:

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

Answer 11

OWASP diskutiert diese:

  

Was ist der Unterschied zwischen den Cache-Control-Richtlinien: no-cache, und no-store

     

Das no-cache-Direktive in einer Antwort zeigt an, dass die Antwort nicht eine nachfolgende Anforderung das heißt den Cache dienen verwendet werden muss, muss eine Antwort nicht angezeigt werden, dass diese Richtlinie im Kopf gesetzt hat, muss jedoch läßt den Server die Anforderung dienen. Der no-cache Direktive kann einige Feldnamen enthalten; in diesem Fall kann die Antwort aus dem Cache angezeigt, außer für die Feldnamen festgelegt, die vom Server bedient werden sollen. Die no-store-Richtlinie gilt für die gesamte Nachricht und zeigt an, dass der Cache nicht Teil der Antwort, oder jede Anforderung, die danach gefragt speichern muß.

     

Bin ich mit diesen Richtlinien absolut sicher?

     

Nein. Aber im Allgemeinen verwendet sowohl Cache-Control: no-cache, no-store und Pragma: no-cache, zusätzlich zu Gültig bis: 0 (oder ein ausreichend rückwirkenden GMT Datum wie die UNIX-Epoche). Nicht-HTML-Inhaltstypen wie PDF, Word-Dokumente, Excel-Tabellen, etc. oft zwischengespeichert erhalten, selbst wenn die oben Cache-Steuerrichtlinien festgelegt sind (obwohl dies variiert je nach Version und zusätzlicher Verwendung von Must-revalidate, Pre-Check = 0, post-Check = 0, maxage = 0 und s-maxage = 0 können in der Praxis manchmal zumindest in Löschen von Dateien auf Browser-Verschluss in einigen Fällen führen aufgrund Browser Macken und HTTP-Implementierungen). Außerdem ermöglicht ‚Automatische Vervollständigung‘ -Funktion ein Browser-Cache unabhängig von den Benutzern in einem Eingabefeld eines Formulars. Um dies zu überprüfen, sollte das Formular-Tag oder die einzelnen Eingangs-Tags enthalten ‚Automatische Vervollständigung =‚Off‘‘ Attribut. Es sollte jedoch beachtet werden, dass dieses Attribut nicht-Standard (obwohl es von den großen Browsern unterstützt wird), so wird es brechen XHTML-Validierung.

hier .