Verhindern der Zwischenspeicherung in Internet-Explorer

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.

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

Zusammenfassung

Sie können Microsoft Internet Information Server (IIS) verwenden, um sehr flüchtige oder vertrauliche Seiten einfach zu markieren, indem Sie das folgende Skript am äußersten Anfang der spezifischen ASP-Seiten (Active Server Pages) verwenden:

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

Ablauf und der Header Expires

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 anfordernde Clients zurückgegeben wird. Die meisten Browser und Zwischenproxys berücksichtigen heute diese Ablaufinformationen und verwenden sie, um die Effizienz der Kommunikation über das Netzwerk zu erhöhen.

Verwenden Sie immer den Expires-Header, um den angemessensten 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 Wir zum Beispiel eine tägliche Nachrichtenseite im Internet, die täglich um 5 Uhr aktualisiert wird. Der Webserver für diese Newsseite sollte einen Expires-Header mit einem Wert für 5:00 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, deren Änderung nicht erwartet wird, sollten mit einem Ablaufdatum von ungefähr einem Jahr gekennzeichnet werden.

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

  • , wenn die Schaltflächen ZURÜCK und VORWÄRTS verwendet werden, um auf den Navigationsverlauf zuzugreifen.
  • , wenn sich der Browser im Offlinemodus befindet.

Der Cache-Control-Header

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

Seiten, die aus dem Cache herausgehalten werden, sind erst zugänglich, wenn der Browser den Webserver erneut kontaktieren kann. Daher sollten Server den Cache-Control-Header sparsam verwenden. In den meisten Fällen wird die Verwendung von Expires: -1 bevorzugt.

Der Pragma: No-Cache-Header

Leider können ältere HTTP 1.0-Server den Cache-Control-Header nicht verwenden. 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 mit dem Server über eine sichere Verbindung (https://) kommuniziert und der Server einen Pragma: no-cache-Header mit der Antwort zurückgibt, speichert Internet Explorer die Antwort nicht zwischen.

Der Pragma: no-cache-Header war jedoch nicht für diesen Zweck 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. Es ist für Proxyserver vorgesehen, die verhindern können, 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 ein kurzes Beispiel für eine HTML-Seite, die sowohl Pragma verwendet: no-cache als auch 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 bei Verwendung über eine sichere Verbindung. Ein Pragma: no-cache META-Tag wird identisch mit Expires: -1 behandelt, 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 haben keine Auswirkungen auf internet Explorer Version 4 oder 5. Um Cache-Control verwenden zu können, muss dieser Header mithilfe von HTTP-Headern angegeben werden, wie im abschnitt Cache-Control oben beschrieben.

Hinweis

Die Verwendung von HTTP-Standardheadern ist 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 in Ihrem 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 mit dem Inhalt, 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 in der Gruppe Benutzerdefinierte HTTP-Header die Schaltfläche Hinzufügen aus, und fügen Sie Cache-Control für den Headernamen und no-cache für den Headerwert hinzu.

Es ist keine gute Idee, diesen Header global auf dem gesamten Webserver zu verwenden. Beschränken Sie die Verwendung ausschließlich auf Inhalte, die unbedingt nicht auf dem Client zwischengespeichert werden dürfen.

Checkliste für Probleme

Wenn Sie die Techniken in diesem Artikel angewendet haben und weiterhin Probleme mit der Zwischenspeicherung und der Internet-Explorer haben, lesen Sie diese praktische Checkliste Schritt für Schritt, bevor Sie sich an Microsoft wenden, um Unterstützung beim technischen Support zu erhalten:

  • Verwenden Sie den Cache-Control-Header mit der ASP-Eigenschaft Response.CacheControl oder über einen zurückgegebenen HTTP-Header? Dies ist die einzige Möglichkeit, das Zwischenspeichern in Internet-Explorer wirklich zu verhindern.
  • Verwenden Sie Internet Explorer 4.01 Service Pack 2 oder höher? Es gibt keine Möglichkeit, das Zwischenspeichern in früheren Versionen des Browsers vollständig zu verhindern.
  • Haben Sie überprüft, ob auf Ihrem Webserver HTTP 1.1 aktiviert ist und HTTP 1.1-Antworten an Internet Explorer zurückgegeben werden? Cache-Control Header sind in HTTP 1.0-Antworten ungültig.
  • Wenn Sie CGI/ISAPI/Servlets auf der Serverseite verwenden, befolgen Sie die HTTP 1.1-Spezifikation genau, insbesondere hinsichtlich der CRLF-Beendigung von HTTP-Headern? Im Interesse der Leistung ist internet Explorer in der Regel unerbittlich gegenüber 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