Freigeben über

Verhindern der Zwischenspeicherung in Internet Explorer

  • Artikel

Warnung

Die eingestellte, nicht mehr unterstützte Desktop-Anwendung Internet Explorer 11 wurde durch ein Microsoft Edge-Update in bestimmten Versionen von Windows 10 dauerhaft deaktiviert. Weitere Informationen finden Sie unter Häufig gestellte Fragen zur Einstellung der Desktop-App von Internet Explorer 11.

In diesem Artikel wird die Verwendung von HTTP-Headern zum Steuern des Zwischenspeicherns von Webseiten in Internet Explorer beschrieben.

Originalproduktversion: Internet Explorer
Ursprüngliche KB-Nummer: 234067

Übersicht

Sie können Microsoft InternetInformation Server (IIS) verwenden, um hochveränderliche oder vertrauliche Seiten einfach zu markieren, indem Sie das folgende Skript am extremen Anfang der spezifischen ASP-Seiten (Active Server Pages) verwenden:

<% Response.CacheControl = "no-cache" %>
<% Response.AddHeader "Pragma", "no-cache" %>
<% Response.Expires = -1 %>

Ablauf- und Ablaufheader

Es wird dringend empfohlen, dass alle Webserver ein Schema für den Ablauf aller Webseiten verwenden. Es ist eine schlechte Methode, dass ein Webserver keine Ablaufinformationen über den HTTP-Expires-Antwortheader für jede Ressource bereitstellt, die an die Anforderung von Clients zurückgegeben wird. Die meisten Browser und Zwischenproxys respektieren diese Ablaufinformationen heute und verwenden sie, um die Effizienz der Kommunikation über das Netzwerk zu erhöhen.

Verwenden Sie immer den Header "Expires", um den sinnvollsten Zeitpunkt anzugeben, zu dem eine bestimmte Datei auf dem Server vom Client aktualisiert werden muss. Wenn Seiten regelmäßig aktualisiert werden, ist der nächste Aktualisierungszeitraum die effizienteste Antwort. Nehmen Sie sich beispielsweise eine tägliche Nachrichtenseite im Internet an, die täglich um 5 Uhr aktualisiert wird. Der Webserver für diese Nachrichtenseite sollte einen Expires-Header mit einem Wert für 5 Uhr am nächsten Tag zurückgeben. Wenn dies abgeschlossen ist, muss der Browser den Webserver erst dann erneut kontaktieren, wenn sich die Seite geändert hat.

Seiten, die nicht erwartet werden, sollten mit einem Ablaufdatum von etwa einem Jahr markiert werden.

In vielen Fällen verfügen Webserver über eine oder mehrere veränderliche Seiten auf einem Server, die Informationen enthalten, die möglicherweise sofort geändert werden können. Diese Seiten sollten vom Server mit dem Wert "-1" für den Expires-Header gekennzeichnet werden. Bei zukünftigen Anforderungen des Benutzers kontaktiert Internet Explorer in der Regel den Webserver für Aktualisierungen auf dieser Seite über eine bedingte If-Modified-Since-Anforderung. Die Seite verbleibt jedoch im Datenträgercache (temporäre Internetdateien). Und die Seite wird in geeigneten Situationen verwendet, ohne sich an den Remotewebserver zu wenden, z. B.:

  • wenn die Schaltflächen "ZURÜCK" und "VORWÄRTS" für den Zugriff auf den Navigationsverlauf verwendet werden.
  • wenn sich der Browser im Offlinemodus befindet.

Der Cache-Steuerelement-Header

Bestimmte Seiten sind jedoch so veränderlich oder vertraulich, dass keine Datenträgerzwischenspeicherung erforderlich ist. Zu diesem Zweck unterstützt Internet Explorer den HTTP 1.1-Cache-Control-Header. Dieser Header verhindert das Zwischenspeichern einer bestimmten Webressource, wenn der No-Cache-Wert von einem HTTP 1.1-Server angegeben wird.

Auf Seiten, die nicht im Cache gespeichert sind, kann erst zugegriffen werden, wenn der Browser den Webserver erneut kontaktieren kann. Server sollten also den Cache-Control-Header sparsam verwenden. In den meisten Fällen wird die Verwendung von "Expires" bevorzugt: -1.

Pragma: No-Cache-Header

Leider können ältere HTTP 1.0-Server den Cache-Control-Header nicht verwenden. Für Die Abwärtskompatibilität mit HTTP 1.0-Servern unterstützt Internet Explorer eine spezielle Verwendung des HTTP Pragma: no-cache-Headers. Wenn der Client mit dem Server über eine sichere Verbindung (https://) kommuniziert und der Server ein Pragma zurückgibt: no-cache header with the response, Internet Explorer doesn't cache the response.

Das Pragma: No-Cache-Header war zu diesem Zweck jedoch nicht vorgesehen. Gemäß den HTTP 1.0- und 1.1-Spezifikationen wird dieser Header nur im Kontext einer Anforderung und nicht im Kontext einer Antwort definiert. Er ist für Proxyserver vorgesehen, die möglicherweise verhindern, dass bestimmte wichtige Anforderungen den Zielwebserver erreichen. Für zukünftige Anwendungen ist der Cache-Control-Header das richtige Mittel zum Steuern der Zwischenspeicherung.

HTTP-EQUIV META-Tags

HTML-Seiten ermöglichen eine spezielle HTTP-EQUIV-Form des META-Tags, die bestimmte HTTP-Header aus dem HTML-Dokument angibt. Hier ist eine kurze BEISPIEL-HTML-Seite, die sowohl Pragma verwendet: no-cache and Expires: -1:

<HTML>
    <HEAD>
        <META HTTP-EQUIV="Pragma" CONTENT="no-cache">
        <META HTTP-EQUIV="Expires" CONTENT="-1">
    </HEAD>
<BODY>
</BODY>
</HTML>

Pragma: No-Cache verhindert die Zwischenspeicherung nur, wenn sie über eine sichere Verbindung verwendet wird. Ein Pragma: No-Cache-META-Tag wird identisch mit "Expires" behandelt: -1, wenn es auf einer nicht sicheren Seite verwendet wird. Die Seite wird zwischengespeichert, aber als sofort abgelaufen markiert.

CACHE-Control META HTTP-EQUIV-Tags werden ignoriert und wirken sich in Internet Explorer-Versionen 4 oder 5 nicht aus. Zur Verwendung des Cache-Steuerelements muss dieser Header mithilfe von HTTP-Headern angegeben werden, wie im Abschnitt "Cache-Control" oben beschrieben.

Notiz

Die Verwendung von standardmäßigen HTTP-Headern wird gegenüber META-Tags sehr bevorzugt. META-Tags müssen in der Regel oben im HTML HEAD-Abschnitt angezeigt werden. Und es gibt mindestens ein bekanntes Problem mit dem Pragma HTTP-EQUIV META-Tag.

Serveroptionen für die Zwischenspeicherung

Wenn der Cache-Control-Header auf Nicht-ASP-Seiten verwendet werden muss, kann es erforderlich sein, Optionen in der Serverkonfiguration zu verwenden, um diesen Header automatisch hinzuzufügen. Informationen zum Hinzufügen von HTTP-Headern zu Serverantworten für ein bestimmtes Verzeichnis finden Sie im Serverdokument. Führen Sie beispielsweise in IIS 4 die folgenden Schritte aus:

  1. Starten Sie den IIS-Manager.
  2. Öffnen Sie in der Computer- und Dienststruktur den Standardwebserver oder den betreffenden Webserver. Suchen Sie das Verzeichnis, das den Inhalt enthält, der den Cache-Control-Header benötigt.
  3. Öffnen Sie das Dialogfeld "Eigenschaften " für dieses Verzeichnis.
  4. Wählen Sie die Registerkarte "HTTP-Header" aus .
  5. Wählen Sie die Schaltfläche "Hinzufügen " in der Gruppe "Benutzerdefinierte HTTP-Header" aus, und fügen Sie "Cache-Control" für den Headernamen und "No-Cache" für den Headerwert hinzu.

Es ist nicht ratsam, diesen Header global auf dem gesamten Webserver zu verwenden. Beschränken Sie die Verwendung ausschließlich auf Inhalte, die absolut nicht auf dem Client zwischengespeichert werden müssen.

Problemprüfliste

Wenn Sie die Techniken in diesem Artikel angewendet haben und weiterhin Probleme mit dem Zwischenspeichern und Internet Explorer haben, lesen Sie diese praktische Checkliste Schritt für Schritt, bevor Sie sich an Microsoft wenden, um technische Supporthilfe zu erhalten:

  • Verwenden Sie den Cache-Control-Header mit der ASP-Eigenschaft Response.CacheControl oder über einen zurückgegebenen HTTP-Header? Es ist die einzige Möglichkeit, die Zwischenspeicherung in Internet Explorer wirklich zu verhindern.
  • Verwenden Sie Internet Explorer 4.01 Service Pack 2 oder höher? Es gibt keine Möglichkeit, zwischenspeichern in früheren Versionen des Browsers vollständig zu verhindern.
  • Haben Sie überprüft, ob ihr Webserver HTTP 1.1 aktiviert hat und HTTP 1.1-Antworten an Internet Explorer zurückgibt? Cachesteuerelement-Header sind in HTTP 1.0-Antworten ungültig.
  • Wenn Sie CGI/ISAPI/Servlets auf serverseitiger Seite verwenden, folgen Sie der HTTP 1.1-Spezifikation genau, insbesondere zum Beenden von CRLF-HTTP-Headern? Im Interesse der Leistung ist Internet Explorer in der Regel unerbittlich von Antworten, die gegen die HTTP 1.1-Spezifikation verstoßen. Dies führt in der Regel zu ignorierten Headern oder Berichten zu unerwarteten Serverfehlern.
  • Sind die HTTP-Header richtig geschrieben?

Siehe auch