Wie steuern wir das Zwischenspeichern von Webseiten in allen Browsern?


1552

Unsere Untersuchungen haben gezeigt, dass nicht alle Browser die HTTP-Cache-Anweisungen einheitlich einhalten.

Aus Sicherheitsgründen möchten wir nicht, dass bestimmte Seiten in unserer Anwendung jemals vom Webbrowser zwischengespeichert werden. Dies muss für mindestens die folgenden Browser funktionieren:

  • Internet Explorer 6+
  • Firefox 1.5+
  • Safari 3+
  • Opera 9+
  • Chrom

Unsere Anforderung ergab sich aus einem Sicherheitstest. Nachdem Sie sich von unserer Website abgemeldet haben, können Sie die Zurück-Taste drücken und zwischengespeicherte Seiten anzeigen.


Hilft [dies] [1] nur für iPad Safari? [1]: stackoverflow.com/questions/24524248/…
Bakhshi

Am einfachsten ist es: max-age = 10. Dies ist nicht perfekt, da die Seite 10 Sekunden lang zwischengespeichert wird. Aber es ist die am wenigsten "Header Spaghetti" -Lösung da draußen. Dies bietet manchmal auch einen großen Leistungsschub bei dynamischen Websites, die Reverse-Proxys verwenden. (Ihr langsames PHP-Skript wird einmal alle 10 Sekunden aufgerufen und dann vom Reverse-Proxy zwischengespeichert. Einmal pro 10 Sekunden ist viel besser als einmal pro Besucher.)
Hello World


3
Vielen Dank für diese tolle Frage. Aus Neugier können Sie möglicherweise Daten senden, ohne dass der Empfänger sie aus "Sicherheitsgründen" speichert . du hast sie schon geschickt!
Buchhalter م

1
@Accountant: In seinem Szenario hatte sich der Benutzer abgemeldet. Wer kann garantieren, dass der nächste menschliche Benutzer auf diesem User-Agent die Person ist, die sich gerade abgemeldet hat?
Fabien Haddadi

Antworten:


2579

Einführung

Der richtige Mindestsatz an Headern, der für alle genannten Clients (und Proxys) funktioniert:

Cache-Control: no-cache, no-store, must-revalidate
Pragma: no-cache
Expires: 0

Das Cache-Controlist für die HTTP 1.1 - Spezifikation für Clients und Proxies (und implizit von einigen Kunden neben erforderlich Expires). Das Pragmaist für die HTTP 1.0 - Spezifikation für prähistorische Kunden. Das Expiresist per HTTP 1.0 und 1.1 Spezifikationen für Clients und Proxies. In HTTP 1.1 hat das Cache-ControlVorrang vor ExpiresHTTP 1.0, also nur für HTTP 1.0-Proxys.

Wenn Sie sich nicht für IE6 und dessen fehlerhaftes Caching interessieren, wenn Sie Seiten nur über HTTPS bereitstellen no-store, können Sie dies weglassen Cache-Control: no-cache.

Cache-Control: no-store, must-revalidate
Pragma: no-cache
Expires: 0

Wenn Sie sich nicht für IE6- oder HTTP 1.0-Clients interessieren (HTTP 1.1 wurde 1997 eingeführt), können Sie dies weglassen Pragma.

Cache-Control: no-store, must-revalidate
Expires: 0

Wenn Sie sich auch nicht für HTTP 1.0-Proxys interessieren, können Sie dies weglassen Expires.

Cache-Control: no-store, must-revalidate

Wenn der Server hingegen automatisch einen gültigen DateHeader enthält, können Sie ihn theoretisch auch weglassen Cache-Controlund sich Expiresnur darauf verlassen.

Date: Wed, 24 Aug 2016 18:32:02 GMT
Expires: 0

Dies kann jedoch fehlschlagen, wenn z. B. der Endbenutzer das Datum des Betriebssystems manipuliert und die Client-Software darauf vertraut.

Andere Cache-ControlParameter wie max-agesind irrelevant, wenn die oben genannten Cache-ControlParameter angegeben werden. Der Last-ModifiedHeader, wie er in den meisten anderen Antworten hier enthalten ist, ist nur dann interessant, wenn Sie die Anforderung tatsächlich zwischenspeichern möchten , sodass Sie sie überhaupt nicht angeben müssen.

Wie stelle ich es ein?

Verwenden von PHP:

header("Cache-Control: no-cache, no-store, must-revalidate"); // HTTP 1.1.
header("Pragma: no-cache"); // HTTP 1.0.
header("Expires: 0"); // Proxies.

Verwenden von Java Servlet oder Node.js:

response.setHeader("Cache-Control", "no-cache, no-store, must-revalidate"); // HTTP 1.1.
response.setHeader("Pragma", "no-cache"); // HTTP 1.0.
response.setHeader("Expires", "0"); // Proxies.

Verwenden von ASP.NET-MVC

Response.Cache.SetCacheability(HttpCacheability.NoCache);  // HTTP 1.1.
Response.Cache.AppendCacheExtension("no-store, must-revalidate");
Response.AppendHeader("Pragma", "no-cache"); // HTTP 1.0.
Response.AppendHeader("Expires", "0"); // Proxies.

Verwenden der ASP.NET-Web-API:

// `response` is an instance of System.Net.Http.HttpResponseMessage
response.Headers.CacheControl = new CacheControlHeaderValue
{
    NoCache = true,
    NoStore = true,
    MustRevalidate = true
};
response.Headers.Pragma.ParseAdd("no-cache");
// We can't use `response.Content.Headers.Expires` directly
// since it allows only `DateTimeOffset?` values.
response.Content?.Headers.TryAddWithoutValidation("Expires", 0.ToString()); 

Verwenden von ASP.NET:

Response.AppendHeader("Cache-Control", "no-cache, no-store, must-revalidate"); // HTTP 1.1.
Response.AppendHeader("Pragma", "no-cache"); // HTTP 1.0.
Response.AppendHeader("Expires", "0"); // Proxies.

Verwenden von ASP.NET Core v3

// using Microsoft.Net.Http.Headers
Response.Headers[HeaderNames.CacheControl] = "no-cache, no-store, must-revalidate";
Response.Headers[HeaderNames.Expires] = "0";
Response.Headers[HeaderNames.Pragma] = "no-cache";

Verwenden von ASP:

Response.addHeader "Cache-Control", "no-cache, no-store, must-revalidate" ' HTTP 1.1.
Response.addHeader "Pragma", "no-cache" ' HTTP 1.0.
Response.addHeader "Expires", "0" ' Proxies.

Verwenden von Ruby on Rails oder Python / Flask:

headers["Cache-Control"] = "no-cache, no-store, must-revalidate" # HTTP 1.1.
headers["Pragma"] = "no-cache" # HTTP 1.0.
headers["Expires"] = "0" # Proxies.

Verwenden von Python / Django:

response["Cache-Control"] = "no-cache, no-store, must-revalidate" # HTTP 1.1.
response["Pragma"] = "no-cache" # HTTP 1.0.
response["Expires"] = "0" # Proxies.

Verwenden von Python / Pyramid:

request.response.headerlist.extend(
    (
        ('Cache-Control', 'no-cache, no-store, must-revalidate'),
        ('Pragma', 'no-cache'),
        ('Expires', '0')
    )
)

Verwenden von Go:

responseWriter.Header().Set("Cache-Control", "no-cache, no-store, must-revalidate") // HTTP 1.1.
responseWriter.Header().Set("Pragma", "no-cache") // HTTP 1.0.
responseWriter.Header().Set("Expires", "0") // Proxies.

Verwenden der Apache- .htaccessDatei:

<IfModule mod_headers.c>
    Header set Cache-Control "no-cache, no-store, must-revalidate"
    Header set Pragma "no-cache"
    Header set Expires 0
</IfModule>

Verwenden von HTML4:

<meta http-equiv="Cache-Control" content="no-cache, no-store, must-revalidate">
<meta http-equiv="Pragma" content="no-cache">
<meta http-equiv="Expires" content="0">

HTML-Meta-Tags im Vergleich zu HTTP-Antwortheadern

Es ist wichtig zu wissen, dass, wenn eine HTML-Seite über eine HTTP-Verbindung bereitgestellt wird und sowohl in den HTTP-Antwortheadern als auch in den HTML- <meta http-equiv>Tags ein Header vorhanden ist, der im HTTP-Antwortheader angegebene den Vorrang vor dem HTML-Meta-Tag hat. Das HTML-Meta-Tag wird nur verwendet, wenn die Seite von einem lokalen Datenträger-Dateisystem über eine file://URL angezeigt wird . Siehe auch W3 HTML-Spezifikation Kapitel 5.2.2 . Seien Sie vorsichtig, wenn Sie sie nicht programmgesteuert angeben, da der Webserver nämlich einige Standardwerte enthalten kann.

Im Allgemeinen sollten Sie die HTML-Meta-Tags nicht angeben, um Verwirrung durch Starter zu vermeiden, und sich auf harte HTTP-Antwortheader verlassen. Darüber hinaus sind speziell diese <meta http-equiv>Tags in HTML5 ungültig . Es sind nur die http-equivin der HTML5-Spezifikation aufgeführten Werte zulässig.

Überprüfen der tatsächlichen HTTP-Antwortheader

Um das eine oder andere zu überprüfen, können Sie sie im HTTP-Verkehrsmonitor des Entwickler-Toolset von Webbrowser anzeigen / debuggen. Sie können dorthin gelangen, indem Sie in Chrome / Firefox23 + / IE9 + F12 drücken, dann die Registerkarte "Netzwerk" oder "Netz" öffnen und dann auf die gewünschte HTTP-Anforderung klicken, um alle Details zur HTTP-Anforderung und -Antwort anzuzeigen. Der folgende Screenshot stammt von Chrome:

HTTP-Verkehrsmonitor für Chrome-Entwicklertools, der HTTP-Antwortheader auf stackoverflow.com anzeigt

Ich möchte diese Header auch für Dateidownloads festlegen

Diese Frage und Antwort richtet sich zunächst auf "Webseiten" (HTML-Seiten) und nicht auf "Dateidownloads" (PDF, Zip, Excel usw.). Sie sollten sie zwischenspeichern lassen und eine Dateiversionskennung irgendwo im URI-Pfad oder im Querystring verwenden, um ein erneutes Herunterladen einer geänderten Datei zu erzwingen. Wenn Sie diese No-Cache-Header ohnehin auf Dateidownloads anwenden, achten Sie auf den IE7 / 8-Fehler, wenn Sie einen Dateidownload über HTTPS anstelle von HTTP bereitstellen. Weitere Informationen finden Sie unter IE kann foo.jsf nicht herunterladen. IE konnte diese Internetseite nicht öffnen. Die angeforderte Site ist entweder nicht verfügbar oder kann nicht gefunden werden .


16
Dies scheint nicht vollständig zu sein. Ich habe diese Lösung in IE 8 ausprobiert und festgestellt, dass der Browser eine zwischengespeicherte Version lädt, wenn Sie auf die Schaltfläche "Zurück" klicken.
Mike Ottum

16
Wahrscheinlich war Ihre Testmethode falsch. Vielleicht war die Seite schon im Cache? Vielleicht waren die Header falsch / überschrieben? Vielleicht haben Sie die falsche Anfrage angesehen? Etc ..
BalusC

8
Tatsächlich bestätige ich, dass dieser Ansatz unvollständig ist und Probleme mit IE8 verursacht, oder zumindest unter bestimmten Umständen. Insbesondere wenn IE8 zum Abrufen einer Ressource über SSL verwendet wird, weigert sich IE8, die Ressource ein zweites Mal abzurufen (entweder überhaupt oder nach einem ersten Versuch, abhängig von den verwendeten Headern). Siehe zum Beispiel EricLaws Blog .
Haylem

21
Ich möchte hinzufügen, dass dies im Wesentlichen das ist, was die Bank of America tut. Wenn Sie sich ihre Antwortheader ansehen und diese in aspx übersetzen, tun sie Folgendes: Response.AppendHeader ("Cache-Control", "kein Cache, kein Speicher, muss erneut validiert werden"); Response.AppendHeader ("Expires", "Do, 01. Dezember 1994, 16:00:00 GMT"); Ich denke, wenn es gut genug für sie ist, ist es gut genug für mich.
John

8
@ John: Dieser Header läuft ab. Dies ist genau der Beispielwert in der HTTP 1.0-Spezifikation . Es funktioniert, aber es ist etwas lächerlich, genau diesen Zeitstempel zu nehmen.
BalusC

244

(Hey, alle zusammen: Bitte kopieren Sie nicht einfach alle Header, die Sie finden können, und fügen Sie sie ein.)

Erstens ist der Verlauf der Zurück-Schaltfläche kein Cache :

Das Frische-Modell (Abschnitt 4.2) gilt nicht unbedingt für Verlaufsmechanismen. Das heißt, ein Verlaufsmechanismus kann eine vorherige Darstellung anzeigen, selbst wenn sie abgelaufen ist.

In der alten HTTP-Spezifikation war der Wortlaut noch stärker und forderte die Browser ausdrücklich auf, Cache-Anweisungen für den Verlauf der Zurück-Schaltflächen zu ignorieren.

Zurück sollte in der Zeit zurückgehen (zu der Zeit , wenn der Benutzer wurde angemeldet). Es wird nicht vorwärts zu einer zuvor geöffneten URL navigiert.

In der Praxis kann der Cache jedoch unter ganz bestimmten Umständen die Zurück-Schaltfläche beeinflussen:

  • Die Seite muss über HTTPS geliefert werden , sonst ist dieses Cache-Busting nicht zuverlässig. Wenn Sie kein HTTPS verwenden, ist Ihre Seite außerdem auf viele andere Arten anfällig für Anmeldediebstahl.
  • Sie müssen senden Cache-Control: no-store, must-revalidate(einige Browser beobachten no-storeund einige beobachten must-revalidate)

Sie brauchen nie eines von:

  • <meta>mit Cache-Headern - es funktioniert überhaupt nicht. Völlig nutzlos.
  • post-check/ pre-check- Es ist eine Nur-IE-Direktive, die nur für zwischenspeicherbare Ressourcen gilt.
  • Senden Sie denselben Header zweimal oder in Dutzend Teilen. Einige PHP-Snippets ersetzen tatsächlich vorherige Header, was dazu führt, dass nur der letzte gesendet wird.

Wenn Sie möchten, können Sie hinzufügen:

  • no-cacheoder max-age=0, wodurch die Ressource (URL) "veraltet" wird und Browser beim Server prüfen müssen, ob es eine neuere Version gibt ( no-storeimpliziert dies bereits noch stärker).
  • Expiresmit einem Datum in der Vergangenheit für HTTP / 1.0-Clients (obwohl echte HTTP / 1.0-Clients heutzutage überhaupt nicht existieren).

Bonus: Der neue HTTP-Caching-RFC .


1
Wird dies einen Einfluss auf die Leistung der Website in Bezug auf die Ladezeit haben? Wie wirkt sich No-Store, No-Cache und Must-Revalidate auf die Leistung aus?
Raman Ghai

@RamanGhai Das Deaktivieren des Cache beeinträchtigt im Allgemeinen die Leistung (und alle drei von Ihnen erwähnten Optionen deaktivieren das Caching). Dies kann dazu führen, dass CDNs und ISP-Proxys (z. B. häufig von Mobilfunkbetreibern verwendet) unwirksam werden. Das erste Laden durch einen neuen Benutzer wird nicht beeinträchtigt (abgesehen vom Proxy-Problem), aber die nachfolgende Navigation kann viel langsamer sein.
Kornel

@porneL Sie geben an, dass wir senden müssen Cache-Control: must-revalidate. Warum nicht senden, Cache-Control: no-cacheda dies no-cachebereits impliziert must-revalidate? w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.9.1
Pacerier

3
@Pacerier Die Beziehung von no-cachemit must-revalidategilt für den Cache, aber der Hintergrundverlauf ist kein Cache. Browser-Sonderfall explizit must-revalidatezur Steuerung des Verlaufsverhaltens .
Kornel

@porneL, Hmm, gibt es einen unterstützenden RFC, der angibt, dass dies das gewünschte Verhalten ist?
Pacerier

103

Wie @Kornel sagte, möchten Sie nicht den Cache deaktivieren, sondern den Verlaufspuffer deaktivieren. Verschiedene Browser haben ihre eigenen subtilen Möglichkeiten, den Verlaufspuffer zu deaktivieren.

In Chrome (v28.0.1500.95 m) können wir dies nur mit tun Cache-Control: no-store.

In FireFox (v23.0.1) funktioniert Folgendes:

  1. Cache-Control: no-store

  2. Cache-Control: no-cache (nur https)

  3. Pragma: no-cache (nur https)

  4. Vary: * (nur https)

In Opera (v12.15) können wir dies nur über Cache-Control: must-revalidate(nur https) tun .

In Safari (v5.1.7, 7534.57.2) funktioniert Folgendes:

  1. Cache-Control: no-store
    <body onunload=""> in html

  2. Cache-Control: no-store (nur https)

In IE8 (v8.0.6001.18702IC) funktioniert eine dieser Funktionen:

  1. Cache-Control: must-revalidate, max-age=0

  2. Cache-Control: no-cache

  3. Cache-Control: no-store

  4. Cache-Control: must-revalidate
    Expires: 0

  5. Cache-Control: must-revalidate
    Expires: Sat, 12 Oct 1991 05:00:00 GMT

  6. Pragma: no-cache (nur https)

  7. Vary: * (nur https)

Wenn wir das oben Genannte kombinieren, erhalten wir diese Lösung, die für Chrome 28, FireFox 23, IE8, Safari 5.1.7 und Opera 12.15 funktioniert: Cache-Control: no-store, must-revalidate (nur https)

Beachten Sie, dass https erforderlich ist, da Opera den Verlaufspuffer für einfache http-Seiten nicht deaktivieren würde. Wenn Sie https wirklich nicht erhalten können und bereit sind, Opera zu ignorieren, können Sie Folgendes tun:

Cache-Control: no-store
<body onunload="">

Unten sehen Sie die Rohprotokolle meiner Tests:

HTTP:

  1. Cache-Control: private, no-cache, no-store, must-revalidate, max-age=0, proxy-revalidate, s-maxage=0
    Expires: 0
    Pragma: no-cache
    Vary: *
    <body onunload="">
    Fehler: Opera 12.15
    Erfolg: Chrome 28, FireFox 23, IE8, Safari 5.1.7

  2. Cache-Control: private, no-cache, no-store, must-revalidate, max-age=0, proxy-revalidate, s-maxage=0
    Expires: Sat, 12 Oct 1991 05:00:00 GMT
    Pragma: no-cache
    Vary: *
    <body onunload="">
    Fehler: Opera 12.15
    Erfolg: Chrome 28, FireFox 23, IE8, Safari 5.1.7

  3. Cache-Control: private, no-cache, no-store, must-revalidate, max-age=0, proxy-revalidate, s-maxage=0
    Expires: 0
    Pragma: no-cache
    Vary: *
    Fehler: Safari 5.1.7, Opera 12.15
    Erfolg: Chrome 28, FireFox 23, IE8

  4. Cache-Control: private, no-cache, no-store, must-revalidate, max-age=0, proxy-revalidate, s-maxage=0
    Expires: Sat, 12 Oct 1991 05:00:00 GMT
    Pragma: no-cache
    Vary: *
    Fehler: Safari 5.1.7, Opera 12.15
    Erfolg: Chrome 28, FireFox 23, IE8

  5. Cache-Control: private, no-cache, must-revalidate, max-age=0, proxy-revalidate, s-maxage=0
    Expires: 0
    Pragma: no-cache
    Vary: *
    <body onunload="">
    Fehler: Chrome 28, FireFox 23, Safari 5.1.7, Opera 12.15
    Erfolg: IE8

  6. Cache-Control: private, no-cache, must-revalidate, max-age=0, proxy-revalidate, s-maxage=0
    Expires: Sat, 12 Oct 1991 05:00:00 GMT
    Pragma: no-cache
    Vary: *
    <body onunload="">
    Fehler: Chrome 28, FireFox 23, Safari 5.1.7, Opera 12.15
    Erfolg: IE8

  7. Cache-Control: private, no-cache, must-revalidate, max-age=0, proxy-revalidate, s-maxage=0
    Expires: 0
    Pragma: no-cache
    Vary: *
    <body onunload="">
    Fehler: Chrome 28, FireFox 23, Safari 5.1.7, Opera 12.15
    Erfolg: IE8

  8. Cache-Control: private, no-cache, must-revalidate, max-age=0, proxy-revalidate, s-maxage=0
    Expires: Sat, 12 Oct 1991 05:00:00 GMT
    Pragma: no-cache
    Vary: *
    <body onunload="">
    Fehler: Chrome 28, FireFox 23, Safari 5.1.7, Opera 12.15
    Erfolg: IE8

  9. Cache-Control: no-store
    Fehler: Safari 5.1.7, Opera 12.15
    Erfolg: Chrome 28, FireFox 23, IE8

  10. Cache-Control: no-store
    <body onunload="">
    Fehler: Opera 12.15
    Erfolg: Chrome 28, FireFox 23, IE8, Safari 5.1.7

  11. Cache-Control: no-cache
    Fehler: Chrome 28, FireFox 23, Safari 5.1.7, Opera 12.15
    Erfolg: IE8

  12. Vary: *
    Fehler: Chrome 28, FireFox 23, IE8, Safari 5.1.7, Opera 12.15
    Erfolg: keine

  13. Pragma: no-cache
    Fehler: Chrome 28, FireFox 23, IE8, Safari 5.1.7, Opera 12.15
    Erfolg: keine

  14. Cache-Control: private, no-cache, must-revalidate, max-age=0, proxy-revalidate, s-maxage=0
    Expires: Sat, 12 Oct 1991 05:00:00 GMT
    Pragma: no-cache
    Vary: *
    <body onunload="">
    Fehler: Chrome 28, FireFox 23, Safari 5.1.7, Opera 12.15
    Erfolg: IE8

  15. Cache-Control: private, no-cache, must-revalidate, max-age=0, proxy-revalidate, s-maxage=0
    Expires: 0
    Pragma: no-cache
    Vary: *
    <body onunload="">
    Fehler: Chrome 28, FireFox 23, Safari 5.1.7, Opera 12.15
    Erfolg: IE8

  16. Cache-Control: must-revalidate, max-age=0
    Fehler: Chrome 28, FireFox 23, Safari 5.1.7, Opera 12.15
    Erfolg: IE8

  17. Cache-Control: must-revalidate
    Expires: 0
    Fehler: Chrome 28, FireFox 23, Safari 5.1.7, Opera 12.15
    Erfolg: IE8

  18. Cache-Control: must-revalidate
    Expires: Sat, 12 Oct 1991 05:00:00 GMT
    Fehler: Chrome 28, FireFox 23, Safari 5.1.7, Opera 12.15
    Erfolg: IE8

  19. Cache-Control: private, must-revalidate, proxy-revalidate, s-maxage=0
    Pragma: no-cache
    Vary: *
    <body onunload="">
    Fehler: Chrome 28, FireFox 23, IE8, Safari 5.1.7, Opera 12.15
    Erfolg: keine

HTTPS:

  1. Cache-Control: private, max-age=0, proxy-revalidate, s-maxage=0
    Expires: 0
    <body onunload="">
    Fehler: Chrome 28, FireFox 23, IE8, Safari 5.1.7, Opera 12.15
    Erfolg: keine

  2. Cache-Control: private, max-age=0, proxy-revalidate, s-maxage=0
    Expires: Sat, 12 Oct 1991 05:00:00 GMT
    <body onunload="">
    Fehler: Chrome 28, FireFox 23, IE8, Safari 5.1.7, Opera 12.15
    Erfolg: keine

  3. Vary: *
    Fehler: Chrome 28, Safari 5.1.7, Opera 12.15
    Erfolg: FireFox 23, IE8

  4. Pragma: no-cache
    Fehler: Chrome 28, Safari 5.1.7, Opera 12.15
    Erfolg: FireFox 23, IE8

  5. Cache-Control: no-cache
    Fehler: Chrome 28, Safari 5.1.7, Opera 12.15
    Erfolg: FireFox 23, IE8

  6. Cache-Control: private, no-cache, max-age=0, proxy-revalidate, s-maxage=0
    Fehler: Chrome 28, Safari 5.1.7, Opera 12.15
    Erfolg: FireFox 23, IE8

  7. Cache-Control: private, no-cache, max-age=0, proxy-revalidate, s-maxage=0
    Expires: 0
    Pragma: no-cache
    Vary: *
    Fehler: Chrome 28, Safari 5.1.7, Opera 12.15
    Erfolg: FireFox 23, IE8

  8. Cache-Control: private, no-cache, max-age=0, proxy-revalidate, s-maxage=0
    Expires: Sat, 12 Oct 1991 05:00:00 GMT
    Pragma: no-cache
    Vary: *
    Fehler: Chrome 28, Safari 5.1.7, Opera 12.15
    Erfolg: FireFox 23, IE8

  9. Cache-Control: must-revalidate
    Fehler: Chrome 28, FireFox 23, IE8, Safari 5.1.7
    Erfolg: Opera 12.15

  10. Cache-Control: private, must-revalidate, proxy-revalidate, s-maxage=0
    <body onunload="">
    Fehler: Chrome 28, FireFox 23, IE8, Safari 5.1.7
    Erfolg: Opera 12.15

  11. Cache-Control: must-revalidate, max-age=0
    Fehler: Chrome 28, FireFox 23, Safari 5.1.7
    Erfolg: IE8, Opera 12.15

  12. Cache-Control: private, no-cache, must-revalidate, max-age=0, proxy-revalidate, s-maxage=0
    Expires: Sat, 12 Oct 1991 05:00:00 GMT
    Pragma: no-cache
    Vary: *
    <body onunload="">
    Fehler: Chrome 28, Safari 5.1.7
    Erfolg: FireFox 23, IE8, Opera 12.15

  13. Cache-Control: private, no-cache, must-revalidate, max-age=0, proxy-revalidate, s-maxage=0
    Expires: 0
    Pragma: no-cache
    Vary: *
    <body onunload="">
    Fehler: Chrome 28, Safari 5.1.7
    Erfolg: FireFox 23, IE8, Opera 12.15

  14. Cache-Control: no-store
    Fehler: Opera 12.15
    Erfolg: Chrome 28, FireFox 23, IE8, Safari 5.1.7

  15. Cache-Control: private, no-cache, no-store, max-age=0, proxy-revalidate, s-maxage=0
    Expires: 0
    Pragma: no-cache
    Vary: *
    <body onunload="">
    Fehler: Opera 12.15
    Erfolg: Chrome 28, FireFox 23, IE8, Safari 5.1.7

  16. Cache-Control: private, no-cache, no-store, max-age=0, proxy-revalidate, s-maxage=0
    Expires: Sat, 12 Oct 1991 05:00:00 GMT
    Pragma: no-cache
    Vary: *
    <body onunload="">
    Fehler: Opera 12.15
    Erfolg: Chrome 28, FireFox 23, IE8, Safari 5.1.7

  17. Cache-Control: private, no-cache
    Expires: Sat, 12 Oct 1991 05:00:00 GMT
    Pragma: no-cache
    Vary: *
    Fehler: Chrome 28, Safari 5.1.7, Opera 12.15
    Erfolg: FireFox 23, IE8

  18. Cache-Control: must-revalidate
    Expires: 0
    Fehler: Chrome 28, FireFox 23, Safari 5.1.7,
    Erfolg: IE8, Opera 12.15

  19. Cache-Control: must-revalidate
    Expires: Sat, 12 Oct 1991 05:00:00 GMT
    Fehler: Chrome 28, FireFox 23, Safari 5.1.7,
    Erfolg: IE8, Opera 12.15

  20. Cache-Control: private, must-revalidate, max-age=0, proxy-revalidate, s-maxage=0
    Expires: 0
    <body onunload="">
    Fehler: Chrome 28, FireFox 23, Safari 5.1.7,
    Erfolg: IE8, Opera 12.15

  21. Cache-Control: private, must-revalidate, max-age=0, proxy-revalidate, s-maxage=0
    Expires: Sat, 12 Oct 1991 05:00:00 GMT
    <body onunload="">
    Fehler: Chrome 28, FireFox 23, Safari 5.1.7,
    Erfolg: IE8, Opera 12.15

  22. Cache-Control: private, must-revalidate
    Expires: Sat, 12 Oct 1991 05:00:00 GMT
    Pragma: no-cache
    Vary: *
    Fehler: Chrome 28, Safari 5.1.7
    Erfolg: FireFox 23, IE8, Opera 12.15

  23. Cache-Control: no-store, must-revalidate

    Fehler : keine Erfolg: Chrome 28, FireFox 23, IE8, Safari 5.1.7, Opera 12.15


3
Ich weiß, dass dies vor ein paar Jahren veröffentlicht wurde, aber es war eine interessante Lektüre. Dieses Problem macht mich seit einigen Monaten verrückt. Der Körper scheint wirklich zu wissen, wie man mit der Cache-Kontrolle umgeht. Ich habe ein paar Leute gesehen, die das benutzt haben, <body onunload="">aber es scheint eher ein Weg zu sein, um das eigentliche Problem zu umgehen. Ich habe versucht, .htaccess zu verwenden und die Header auf diese Weise zu ändern. Wenn ich HTTPS verwende, sollte es dann so funktionieren? Es ist hauptsächlich eine Safari, bei der das Problem am meisten auftritt.
Jordanien

4
@ Jordan, Gemäß den obigen Protokollen Cache-Control: no-storewürde das Hinzufügen den Trick tun, wenn Sie HTTPS haben . <body onunload="">wird nur benötigt, wenn Sie kein HTTPS haben.
Pacerier

37

Ich fand die Route web.config nützlich (habe versucht, sie der Antwort hinzuzufügen, scheint aber nicht akzeptiert worden zu sein, also poste ich hier)

<configuration>
<system.webServer>
    <httpProtocol>
        <customHeaders>
            <add name="Cache-Control" value="no-cache, no-store, must-revalidate" />
            <!-- HTTP 1.1. -->
            <add name="Pragma" value="no-cache" />
            <!-- HTTP 1.0. -->
            <add name="Expires" value="0" />
            <!-- Proxies. -->
        </customHeaders>
    </httpProtocol>
</system.webServer>

Und hier ist die Methode von express / node.j, um dasselbe zu tun:

app.use(function(req, res, next) {
    res.setHeader('Cache-Control', 'no-cache, no-store, must-revalidate');
    res.setHeader('Pragma', 'no-cache');
    res.setHeader('Expires', '0');
    next();
});

Für web.config würde ich nur ein wenig ändern, um die benutzerdefinierten Header nur für die Skripte anzuwenden, von denen wir wissen, dass sie dynamisch geladen werden / requirejs verwenden. Angenommen, Ihre Skripte befinden sich im Client-Ordner: <location path = "client"> ..... </ location>
Ibrahim ben Salah

Für diejenigen, die sich fragen, was web.confist: Es ist die Haupteinstellungen und Konfigurationsdatei für eine ASP.NETWebanwendung. Es ist ein XML-Dokument, das sich im Stammverzeichnis befindet. ( Wiki ).
weiterer

27

Ich stellte fest, dass alle Antworten auf dieser Seite immer noch Probleme hatten. Insbesondere ist mir aufgefallen, dass keiner von ihnen IE8 daran hindern würde, eine zwischengespeicherte Version der Seite zu verwenden, wenn Sie darauf zugreifen, indem Sie auf die Schaltfläche "Zurück" klicken.

Nach vielen Recherchen und Tests stellte ich fest, dass die einzigen zwei Header, die ich wirklich brauchte, waren:

Cache-Kontrolle: No-Store
Variieren: *

Eine Erläuterung des Vary-Headers finden Sie unter http://www.w3.org/Protocols/rfc2616/rfc2616-sec13.html#sec13.6

Unter IE6-8, FF1.5-3.5, Chrome 2-3, Safari 4 und Opera 9-10 haben diese Header dazu geführt, dass die Seite vom Server angefordert wurde, wenn Sie auf einen Link zur Seite klicken oder die URL eingeben direkt in der Adressleiste. Das deckt ungefähr 99% aller Browser ab, die ab dem 10. Januar verwendet werden.

Unter IE6 und Opera 9-10 führte das Drücken der Zurück-Taste weiterhin zum Laden der zwischengespeicherten Version. In allen anderen von mir getesteten Browsern wurde eine neue Version vom Server abgerufen. Bisher habe ich keine Header gefunden, die dazu führen, dass diese Browser keine zwischengespeicherten Versionen von Seiten zurückgeben, wenn Sie auf die Schaltfläche "Zurück" klicken.

Update: Nachdem ich diese Antwort geschrieben hatte, stellte ich fest, dass sich unser Webserver als HTTP 1.0-Server identifiziert. Die von mir aufgelisteten Header sind die richtigen, damit Antworten von einem HTTP 1.0-Server nicht von Browsern zwischengespeichert werden. Schauen Sie sich für einen HTTP 1.1-Server die Antwort von BalusC an .


4
Dies funktioniert für den Zurück-Button des IE8 !! Nachdem Sie in jedem anderen Vorschlag alles versucht haben, ist das Hinzufügen des Headers "Variieren: *" anscheinend das einzige, was IE8 zwingen kann, die Seite neu zu laden, wenn der Benutzer die Zurück-Taste drückt. Dies funktioniert auf HTTP / 1.1-Servern.
Coredumperror

In Kombination mit den von BarlusC vorgeschlagenen Headern und einem JS-Snippet, das window.location.reload () aufruft, wenn das Ereignis onPageShow mit dem Attribut "persisted" (für Safari erforderlich) ausgelöst wird, erzwingt jeder von mir getestete Browser erfolgreich ein erneutes Laden von Server, wenn der Benutzer die Schaltfläche Zurück verwendet.
Coredumperror

1
@CoreDumpError, oh, Sie sollten nicht davon ausgehen, dass JavaScript aktiviert ist.
Pacerier

@Pacerier Als ich 2010 die Antwort schrieb, funktionierte dies auf den damals neuesten Versionen von Safari und Opera, wobei sich unser Server als HTTP 1.0-Server identifizierte. Leider kann ich dies nicht mehr einfach testen, daher kann ich nichts Bestimmtes über die neuesten Versionen dieser Browser sagen.
Chris Vasselli

Mit welchen Browserversionen haben Sie getestet?
Pacerier

21

Nach ein wenig Recherche haben wir die folgende Liste von Headern erstellt, die die meisten Browser abzudecken schienen:

In ASP.NET haben wir diese mithilfe des folgenden Snippets hinzugefügt:

Response.ClearHeaders(); 
Response.AppendHeader("Cache-Control", "no-cache"); //HTTP 1.1
Response.AppendHeader("Cache-Control", "private"); // HTTP 1.1
Response.AppendHeader("Cache-Control", "no-store"); // HTTP 1.1
Response.AppendHeader("Cache-Control", "must-revalidate"); // HTTP 1.1
Response.AppendHeader("Cache-Control", "max-stale=0"); // HTTP 1.1 
Response.AppendHeader("Cache-Control", "post-check=0"); // HTTP 1.1 
Response.AppendHeader("Cache-Control", "pre-check=0"); // HTTP 1.1 
Response.AppendHeader("Pragma", "no-cache"); // HTTP 1.0 
Response.AppendHeader("Expires", "Mon, 26 Jul 1997 05:00:00 GMT"); // HTTP 1.0 

Gefunden von: http://forums.asp.net/t/1013531.aspx


36
@bart: Noch problematischer ist, dass der 26. Juli 1997 ein Samstag war, kein Montag ...
13.

5
Cache-Control: no-cacheund Cache-Control: privateZusammenstoß - Sie sollten niemals beides zusammenbringen: Ersteres weist Browser und Proxys an, überhaupt nicht zwischenzuspeichern, letzteres weist Proxys an, nicht zwischenzuspeichern, sondern lässt Browser ihre eigene private Kopie halten. Ich bin nicht sicher, welcher Einstellung der Browser folgen wird, aber es ist unwahrscheinlich, dass sie zwischen Browsern und Versionen konsistent ist.
Keith

Verwenden Sie keine Vor- und Nachprüfung. blogs.msdn.com/b/ieinternals/archive/2009/07/20/…
EricLaw

Dies hat bei mir nicht funktioniert - mit asp.net 4.5 wird der Code ausgeführt, führt jedoch nicht zum erforderlichen Ergebnis. Ich musste folgendes befolgen: stackoverflow.com/questions/22443932/…
Andy

8

Die Verwendung des Pragma-Headers in der Antwort ist eine Frauengeschichte. RFC2616 definiert es nur als Anforderungsheader

http://www.mnot.net/cache_docs/#PRAGMA


4
Dies ist ein gutes Beispiel dafür, warum Sie über die Spezifikationen hinausgehen müssen. Wenn die Spezifikationen immer kristallklar wären, hätte Sites wie StackOverflow nicht viel Sinn. Von Microsoft Aus Gründen der Abwärtskompatibilität mit HTTP 1.0-Servern unterstützt Internet Explorer eine spezielle Verwendung des HTTP Pragma: No-Cache-Headers. Wenn der Client über eine sichere Verbindung (https: //) mit dem Server kommuniziert und der Server einen Pragma: No-Cache-Header mit der Antwort zurückgibt, speichert Internet Explorer die Antwort nicht zwischen.
Michaelok

@michaelok: Ihre Referenz ist gültig, verfehlt aber den größeren Punkt - Stellen Sie eine richtige Cache-Kontrolle ein / Läuft ab und Sie brauchen kein Pragma.
EricLaw

8

HAFTUNGSAUSSCHLUSS: Ich empfehle dringend, die Antwort von @ BalusC zu lesen. Nachdem Sie das folgende Caching-Tutorial gelesen haben : http://www.mnot.net/cache_docs/ (ich empfehle Ihnen, es auch zu lesen), glaube ich, dass es korrekt ist. Aus historischen Gründen (und weil ich es selbst getestet habe) werde ich meine ursprüngliche Antwort unten einfügen:


Ich habe die 'akzeptierte' Antwort für PHP ausprobiert, was bei mir nicht funktioniert hat. Dann habe ich ein wenig recherchiert, eine leichte Variante gefunden, sie getestet und es hat funktioniert. Hier ist es:

header('Cache-Control: no-store, private, no-cache, must-revalidate');     // HTTP/1.1
header('Cache-Control: pre-check=0, post-check=0, max-age=0, max-stale = 0', false);  // HTTP/1.1
header('Pragma: public');
header('Expires: Sat, 26 Jul 1997 05:00:00 GMT');                  // Date in the past  
header('Expires: 0', false); 
header('Last-Modified: '.gmdate('D, d M Y H:i:s') . ' GMT');
header ('Pragma: no-cache');

Das sollte funktionieren. Das Problem bestand darin, dass beim zweimaligen Setzen desselben Teils des Headers falsedie Header-Funktion den vorherigen header()Aufruf einfach überschreibt , wenn der nicht als zweites Argument an die Header-Funktion gesendet wird . Also, wenn die Einstellung Cache-Control, zum Beispiel , wenn man nicht alle Argumente in einer setzen möchte header()Funktionsaufruf, muss er so etwas tun:

header('Cache-Control: this');
header('Cache-Control: and, this', false);

Eine ausführlichere Dokumentation finden Sie hier .


14
Das ist voller Mythen. Pre-Check und Post-Check sind nur IE-fähig, nur für zwischengespeicherte Antworten relevant, und der Wert 0 ist ein No-Op. max-stale ist der Proxy-Anforderungsheader, nicht der Serverantwortheader. Läuft ab akzeptiert nur einen einzelnen Wert. Bei mehr als einem wird dieser Header ignoriert.
Kornel

1
@porneL, werden Sie eine konkurrierende Antwort einreichen, die diese Mythen richtig behandelt?
Oddthinking

@Oddthinking, sieht aus wie stackoverflow.com/questions/49547/… eine konkurrierende Antwort ist.
Mike Ottum

@ Pacerier Ja, wie ich im Haftungsausschluss sage, verwenden Sie die Antwort von BalusC.
Steven Oxley

8

Erstellen Sie für ASP.NET Core eine einfache Middleware-Klasse:

public class NoCacheMiddleware
{
    private readonly RequestDelegate m_next;

    public NoCacheMiddleware( RequestDelegate next )
    {
        m_next = next;
    }

    public async Task Invoke( HttpContext httpContext )
    {
        httpContext.Response.OnStarting( ( state ) =>
        {
            // ref: http://stackoverflow.com/questions/49547/making-sure-a-web-page-is-not-cached-across-all-browsers
            httpContext.Response.Headers.Append( "Cache-Control", "no-cache, no-store, must-revalidate" );
            httpContext.Response.Headers.Append( "Pragma", "no-cache" );
            httpContext.Response.Headers.Append( "Expires", "0" );
            return Task.FromResult( 0 );
        }, null );

        await m_next.Invoke( httpContext );
    }
}

dann registrieren Sie es mit Startup.cs

app.UseMiddleware<NoCacheMiddleware>();

Stellen Sie sicher, dass Sie dies irgendwo später hinzufügen

app.UseStaticFiles();

Ich würde vorschlagen, Konstanten von Microsoft.Net.Http.Headers.HeaderNames anstelle der Zeichenfolgenliterale "Cache-Controls", "Pragma" und "Expires" zu verwenden.
Victor Sharovatov

7

Diese Richtlinien mindern kein Sicherheitsrisiko. Sie sollen UAs dazu zwingen, flüchtige Informationen zu aktualisieren, und UAs nicht davon abhalten, Informationen zu speichern. Siehe diese ähnliche Frage . Zumindest gibt es keine Garantie dafür, dass Router, Proxys usw. die Caching-Anweisungen ebenfalls nicht ignorieren.

Positiv zu vermerken ist, dass Sie mit Richtlinien zum physischen Zugriff auf Computer, zur Softwareinstallation und dergleichen den meisten Unternehmen in Bezug auf die Sicherheit weit voraus sind. Wenn die Verbraucher dieser Informationen Mitglieder der Öffentlichkeit sind, können Sie ihnen nur helfen, zu verstehen, dass diese Maschine, sobald die Informationen auf ihren Computer gelangen, in ihrer Verantwortung liegt und nicht in Ihrer.


7

Es gibt einen Fehler in IE6

Inhalte mit "Content-Encoding: gzip" werden immer zwischengespeichert, auch wenn Sie "Cache-Control: no-cache" verwenden.

http://support.microsoft.com/kb/321722

Sie können die gzip-Komprimierung für IE6-Benutzer deaktivieren (überprüfen Sie den Benutzeragenten auf "MSIE 6").


6

Der RFC für HTTP 1.1 besagt, dass die richtige Methode darin besteht, einen HTTP-Header hinzuzufügen für:

Cache-Kontrolle: kein Cache

Ältere Browser ignorieren dies möglicherweise, wenn sie nicht ordnungsgemäß mit HTTP 1.1 kompatibel sind. Für diejenigen können Sie den Header versuchen:

Pragma: kein Cache

Dies soll auch für HTTP 1.1-Browser funktionieren.


1
Die Spezifikation gibt an, dass die Antwort nicht ohne erneute Validierung wiederverwendet werden darf. Es ist das Cache-Control: no-store, das die offizielle Methode ist, um anzuzeigen, dass die Antwort überhaupt nicht in einem Cache gespeichert wird.
AnthonyWJones

6

Das Setzen des geänderten http-Headers auf ein Datum im Jahr 1995 reicht normalerweise aus.

Hier ist ein Beispiel:

Läuft ab: Mi, 15. November 1995 04:58:08 GMT
Letzte Änderung: Mi, 15. November 1995, 04:58:08 GMT
Cache-Kontrolle: kein Cache, muss erneut validiert werden

1
Das Festlegen einer vor langer Zeit vorgenommenen Änderung hat keine Auswirkungen auf das Caching, außer dass eine zwischengespeicherte Antwort aufgrund heuristischer Revalidierung länger verwendet werden kann.
EricLaw

6

Die PHP-Dokumentation für die Header-Funktion enthält ein ziemlich vollständiges Beispiel (von einem Dritten beigesteuert):

    header('Pragma: public');
    header("Expires: Sat, 26 Jul 1997 05:00:00 GMT");                  // Date in the past   
    header('Last-Modified: '.gmdate('D, d M Y H:i:s') . ' GMT');
    header('Cache-Control: no-store, no-cache, must-revalidate');     // HTTP/1.1
    header('Cache-Control: pre-check=0, post-check=0, max-age=0', false);    // HTTP/1.1
    header ("Pragma: no-cache");
    header("Expires: 0", false);

11
Das ist offensichtlich falsch. Zweite Aufrufe von header () für Expires, Cache-Control und Pragma überschreiben zuvor festgelegte Werte vollständig.
Kornel

1
@porneL: Nein, die zuvor eingestellten Werte werden nicht überschrieben, da er als zweiten Parameter false übergibt und die vorherigen Werte nicht überschreibt.
Julien Palard

1
@ JulienPalard Die Antwort wurde bearbeitet, nachdem ich meinen Kommentar abgegeben habe. Es macht immer noch nicht viel Sinn.
Kornel

Senden Sie nicht mehrere Cache-Control-Header, wenn Sie vor 9 im IE arbeiten möchten. Senden Sie NIEMALS Vor- oder Nachprüfungen. blogs.msdn.com/b/ieinternals/archive/2009/07/20/…
EricLaw

6

Wenn Sie Downloadprobleme mit IE6-IE8 über SSL und Cache: No-Cache-Header (und ähnliche Werte) mit MS Office-Dateien haben, können Sie Cache: Private, No-Store-Header und Rückgabedatei auf POST-Anforderung verwenden. Es klappt.


6

in meinem Fall behebe ich das Problem in Chrom damit

<form id="form1" runat="server" autocomplete="off">

wo ich den Inhalt eines vorherigen Formulars löschen muss, wenn die Benutzer aus Sicherheitsgründen auf die Schaltfläche zurück klicken


Mein Mozilla 19.x-Browserproblem wurde auch durch das Code-Snippet behoben. autocomplete = "aus". Vielen Dank.
Satya

5

Die akzeptierte Antwort scheint für IIS7 + nicht zu funktionieren, da viele Fragen zu Cache-Headern in II7 nicht gesendet wurden:

Und so weiter

Die akzeptierte Antwort ist korrekt, in welchen Headern gesetzt werden muss, nicht jedoch, wie sie gesetzt werden müssen. Diese Methode funktioniert mit IIS7:

Response.Cache.SetCacheability(HttpCacheability.NoCache);
Response.Cache.AppendCacheExtension("no-store, must-revalidate");
Response.AppendHeader("Pragma", "no-cache");
Response.AppendHeader("Expires", "-1");

Die erste Zeile wird Cache-controlauf gesetzt no-cacheund die zweite Zeile fügt die anderen Attribute hinzuno-store, must-revalidate


Das funktioniert bei mir:Response.Cache.SetAllowResponseInBrowserHistory(false); Response.Cache.SetCacheability(HttpCacheability.NoCache); Response.Cache.SetNoStore(); Response.Cache.SetRevalidation(HttpCacheRevalidation.AllCaches);
Vilx

4

Ich habe in allen Browsern die besten und beständigsten Ergebnisse erzielt, indem ich Pragma: no-cache eingestellt habe


4

Die Überschriften in der Antwort von BalusC hindern Safari 5 (und möglicherweise auch ältere Versionen) nicht daran, Inhalte aus dem Browser-Cache anzuzeigen, wenn Sie die Zurück-Schaltfläche des Browsers verwenden. Eine Möglichkeit, dies zu verhindern, besteht darin, dem body-Tag ein leeres onunload-Ereignishandlerattribut hinzuzufügen:

<body onunload=""> 

Dieser Hack bricht anscheinend den Back-Forward-Cache in Safari: Gibt es ein browserübergreifendes Onload-Ereignis, wenn Sie auf die Schaltfläche "Zurück" klicken?


Cool, ich habe es getestet und das funktioniert tatsächlich auf Safari (5.1.7), aber nicht auf Opera.
Pacerier

4

Stellen Sie außerdem sicher, dass Sie das ExpiresDefaultin Ihrer .htaccessDatei zurücksetzen, wenn Sie dies verwenden, um das Caching zu aktivieren.

ExpiresDefault "access plus 0 seconds"

Anschließend können Sie ExpiresByTypebestimmte Werte für die Dateien festlegen, die Sie zwischenspeichern möchten:

ExpiresByType image/x-icon "access plus 3 month"

Dies kann auch nützlich sein, wenn Ihre dynamischen Dateien, z. B. PHP usw., vom Browser zwischengespeichert werden und Sie nicht herausfinden können, warum. Überprüfen Sie ExpiresDefault.


3

Zusätzlich zu den Headern sollten Sie Ihre Seite über https bereitstellen . Viele Browser speichern https standardmäßig nicht zwischen.


3
//In .net MVC
[OutputCache(NoStore = true, Duration = 0, VaryByParam = "*")]
public ActionResult FareListInfo(long id)
{
}

// In .net webform
<%@ OutputCache NoStore="true" Duration="0" VaryByParam="*" %>

2

So vervollständigen Sie BalusC -> ANTWORT Wenn Sie Perl verwenden, können Sie mit CGI HTTP-Header hinzufügen.

Verwenden von Perl:

Use CGI;    
sub set_new_query() {
        binmode STDOUT, ":utf8";
        die if defined $query;
        $query = CGI->new();
        print $query->header(
                        -expires       => 'Sat, 26 Jul 1997 05:00:00 GMT',
                        -Pragma        => 'no-cache',
                        -Cache_Control => join(', ', qw(
                                            private
                                            no-cache
                                            no-store
                                            must-revalidate
                                            max-age=0
                                            pre-check=0
                                            post-check=0 
                                           ))
        );
    }

Verwenden von Apache httpd.conf

<FilesMatch "\.(html|htm|js|css|pl)$">
FileETag None
<ifModule mod_headers.c>
Header unset ETag
Header set Cache-Control "max-age=0, no-cache, no-store, must-revalidate"
Header set Pragma "no-cache"
Header set Expires "Wed, 11 Jan 1984 05:00:00 GMT"
</ifModule>

Hinweis: Als ich versuchte, die HTML-META zu verwenden, haben die Browser diese ignoriert und die Seite zwischengespeichert.


0

Ich möchte nur darauf hinweisen, dass das Hinzufügen dieser zusätzlichen Header programmgesteuert erfolgen sollte, wenn jemand verhindern möchte, dass NUR dynamische Inhalte zwischengespeichert werden.

Ich habe die Konfigurationsdatei meines Projekts so bearbeitet, dass keine Cache-Header angehängt werden. Dadurch wurde jedoch auch das Zwischenspeichern von statischem Inhalt deaktiviert, was normalerweise nicht wünschenswert ist. Durch Ändern der Antwortheader im Code wird sichergestellt, dass Bilder und Stildateien zwischengespeichert werden.

Dies ist ziemlich offensichtlich und dennoch erwähnenswert.

Und noch eine Vorsicht. Seien Sie vorsichtig mit der ClearHeaders-Methode aus der HttpResponse-Klasse. Es kann einige blaue Flecken verursachen, wenn Sie es rücksichtslos verwenden. Als ob es mir gegeben hätte.

Nach der Umleitung zum ActionFilterAttribute-Ereignis gehen beim Löschen aller Header alle Sitzungsdaten und Daten im TempData-Speicher verloren. Es ist sicherer, von einer Aktion umzuleiten oder Header nicht zu löschen, wenn eine Umleitung stattfindet.

Beim zweiten Gedanken rate ich allen davon ab, die ClearHeaders-Methode zu verwenden. Es ist besser, Header separat zu entfernen. Und um den Cache-Control-Header richtig einzustellen, verwende ich diesen Code:

filterContext.HttpContext.Response.Cache.SetCacheability(HttpCacheability.NoCache);
filterContext.HttpContext.Response.Cache.AppendCacheExtension("no-store, must-revalidate");

0

Ich hatte kein Glück mit <head><meta>Elementen. Das direkte Hinzufügen von HTTP-Cache-bezogenen Parametern (außerhalb des HTML-Dokuments) funktioniert in der Tat für mich.

Es web.headerfolgt ein Beispielcode in Python mit web.py- Aufrufen. Ich habe meinen persönlichen irrelevanten Dienstprogrammcode absichtlich redigiert.

    Web importieren
    sys importieren
    PERSÖNLICHE NUTZEN importieren

    myname = "main.py"

    urls = (
        '/', 'Hauptklasse'
    )

    main = web.application (URLs, Globals ())

    render = web.template.render ("templates /", base = "layout", cache = False)

    Klasse main_class (Objekt):
        def GET (Selbst):
            web.header ("Cache-Kontrolle", "kein Cache, kein Speicher, muss erneut validiert werden")
            web.header ("Pragma", "kein Cache")
            web.header ("Läuft ab", "0")
            return render.main_form ()

        def POST (Selbst):
            msg = "POSTed:"
            form = web.input (function = None)
            web.header ("Cache-Kontrolle", "kein Cache, kein Speicher, muss erneut validiert werden")
            web.header ("Pragma", "kein Cache")
            web.header ("Läuft ab", "0")
            return render.index_laid_out (Begrüßung = msg + form.function)

    if __name__ == "__main__":
        nargs = len (sys.argv)
        # Stellen Sie sicher, dass nach dem Namen des Python-Programms genügend Argumente vorhanden sind
        wenn nargs! = 2:
            LOG-AND-DIE ("% s: Befehlszeilenfehler, nargs =% s, sollte 2 sein", myname, nargs)
        # Stellen Sie sicher, dass die TCP-Portnummer numerisch ist
        Versuchen:
            tcp_port = int (sys.argv [1])
        außer Ausnahme als e:
            LOG-AND-DIE ("% s: tcp_port = int (% s) fehlgeschlagen (keine Ganzzahl)", myname, sys.argv [1])
        # Alles ist gut!
        JUST-LOG ("% s: Wird auf Port% d ausgeführt", myname, tcp_port)
        web.httpserver.runsimple (main.wsgifunc (), ("localhost", tcp_port))
        main.run ()


Wird dies nicht schon oft in den Antworten behandelt, die seit Jahren auf der Website sind?
Martin Tournoij

META-Anweisungen funktionieren in Internet Explorer und Versionen von Edge 18 und früheren Versionen. Moderne Browser unterstützen sie nicht. crbug.com/2763
EricLaw

0

Siehe diesen Link zu einer Fallstudie zum Caching:

http://securityevaluators.com/knowledge/case_studies/caching/

Zusammenfassung Cache-Control: no-storefunktioniert laut Artikel nur unter Chrome, Firefox und IE. IE akzeptiert andere Steuerelemente, Chrome und Firefox jedoch nicht. Der Link ist eine gute Lektüre mit der Geschichte des Zwischenspeicherns und der Dokumentation von Proof of Concept.


0

Ich bin mir nicht sicher, ob meine Antwort einfach und dumm klingt, und vielleicht ist sie Ihnen schon vor langer Zeit bekannt, aber da es eines Ihrer Ziele ist, jemanden daran zu hindern, die Browser-Zurück-Schaltfläche zum Anzeigen Ihrer historischen Seiten zu verwenden, können Sie Folgendes verwenden:

window.location.replace("https://www.example.com/page-not-to-be-viewed-in-browser-history-back-button.html");

Natürlich kann dies möglicherweise nicht auf der gesamten Site implementiert werden, aber zumindest für einige kritische Seiten können Sie dies tun. Hoffe das hilft.


-1

Sie können den Standortblock verwenden, um einzelne Dateien festzulegen, anstatt die gesamte App in IIS zwischenzuspeichern

 <location path="index.html">
    <system.webServer>
      <httpProtocol>
        <customHeaders>
          <add name="Cache-Control" value="no-cache" />
        </customHeaders>
      </httpProtocol>
    </system.webServer>
  </location>
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.