Browser-Cache

„Ressource“ ist alles, was über eine bestimmte URL abgerufen werden kann. Zu verschiedenen Zeiten können unter derselben URL unterschiedliche Inhalte vorhanden sein. Im Cache wird jeder URL der zuletzt bekanntgewordene Inhalt zugeordnet.

Das gleiche Konzept für einen Browser-Cache auf dem PC eines Benutzers wird auch von sogenannten Proxy-Servern für ganze Rechnernetze genutzt, etwa für einen Firmenstandort oder eine Universität an der Verbindungsstelle zum Internet oder aber für alle Kunden eines (physischen) Telekommunikationsanbieters in einem Versorgungsbereich. Sie liefern allen angeschlossenen Teilnehmern dieses Netzwerks häufig gefragte Dateien direkt, ohne erst das eigentliche Internet durchlaufen zu müssen.

Caching kommt grundsätzlich für jedes Protokoll in Frage, das Ressourcen abrufbar macht. Praktisch wird es aber nur für HTTP/HTTPS benutzt. Wer mit dem Browser über FTP einen Datei-Download anfordert, wird in diesem Moment eine frische Version erhalten; allerdings könnte ein Proxy-Server Kopien häufig gewünschter Dateien vorhalten. mailto: verschickt Daten und ruft sie nicht ab. Andere Protokolle für Ressourcen bieten keine besondere Unterstützung für das Versionsmanagement und sind heute auch kaum noch gebräuchlich.

Bei einem Browser haben Benutzer allgemein folgende Möglichkeiten, über Konfigurationseinstellungen oder interaktiv das Verhalten des Cache zu beeinflussen:

• Maximalgröße des Festplattenspeicherplatzes festlegen; bei null erfolgt kein Caching.
• Aktuelle Seite neu vom Server abrufen (beträfe die in der Adresszeile sichtbare URL; Einzelseite, oder eine Grafik).
• Aktuelle Seite und alle darin eingebundenen Ressourcen (Bilder, Skripte, Stile usw.) neu abrufen (beträfe meist nur HTML-Seiten).
• Gesamten Cache leeren, möglicherweise auch selektiv nur für alle Ressourcen einer bestimmten Domain (der aktuellen Seite).
• Am Ende (oder ersatzweise zu Beginn) jeder Sitzung den gesamten Cache leeren.
• Höchstalter für Ressourcen festlegen.

Es gelten folgende Grundsätze auf Seiten der Browser oder Proxy-Server:

• Kein System ist verpflichtet, irgendwelche Hinweise des Ursprungs der Ressource zu beachten.
• Im Interesse eines attraktiven Angebots sind die Entwickler von Browsern interessiert, Informationen zum Cache Management auszuwerten, um die Seiten sowohl schnell als auch auf aktuellem Stand darzustellen.

Umfangreiche Anregungen wurden schon 1997 in RFC 2068^[1] und 1999 in RFC 2616^[2] gegeben, müssen aber nicht vollständig umgesetzt sein.

Ein Webserver sollte zu jeder einzelnen Ressource Cache-Informationen (Metadaten) mitliefern, um dem Benutzer eine aktuelle Darstellung zu gewährleisten und möglichst geringen Kommunikationsaufwand für Benutzer wie Server zu erreichen.

Der Betreiber des Webservers profitiert davon, dass er nicht ständig Abfragen nach unveränderten Ressourcen beantworten und dafür Rechner- und Netzwerkkapazität aufwenden muss.

Um die Häufigkeit besuchter Seiten und Informationen über die Leser zu erhalten, verwendet man hingegen sehr kleine eingebettete Schnipsel, bei denen man die Aufnahme in den Cache geeignet verhindert und ein erneutes Abrufen bei jedem Darstellen der Seite erzwingt.

Zum Cache Management wird für jede einzelne Ressource wahlweise einer von zwei Identifizierern verwendet, sofern vom Server beigefügt:

Timestamp

Banaler Zeitstempel in UTC

Feld: Last-Modified

ETag^[3]

Unterscheidung inhaltlich wesentlich verschiedener Versionen einer Ressource.
Kann grundsätzlich auch ein Timestamp sein; jedoch etwa auch eine fortlaufend gezählte Versionsnummer oder ein Hashcode.

Feld: ETag

Fehlen derartige Informationen, dann kennt das Cache Management nur den Zeitpunkt des letzten erfolgreichen Abrufs.

Folgende Methoden stehen zur Verfügung:

Heuristische Schätzungen

Das Cache Management bestimmt nach eigenen Algorithmen, welche Ressource verbleiben sollen und welche zu entfernen sind. Dies wird insbesondere angewendet, wenn der Ressource keine entsprechenden Informationen mitgegeben wurden.

• Ressourcen unbegrenzt belassen, wenn der zugelassene Festplattenspeicherplatz ausreicht; erst bei Platzproblemen geeignet löschen.
• Ressourcen, die vor kurzer Zeit benutzt wurden, könnten vielleicht bald wieder benötigt werden. Lange Zeit nicht angesprochene Ressourcen sind zu löschen.
• Ressourcen, die häufig angesprochen werden, sollen behalten werden. Selten und lange Zeit nicht gefragte Ressourcen sind zu löschen.
• Dateigröße – sehr große, lange Zeit nicht und insgesamt selten benötigte Ressourcen zuerst löschen; dafür viele kleine Ressourcen eher belassen.
• Stabilität – mehrfach veränderte Inhalte sind Löschkandidaten. Über Jahre und mehrere Gültigkeitsprüfungen hinweg unveränderte Ressourcen sollten behalten werden, wenn sie öfters benutzt werden. Kurze Restlaufzeiten sind ein Indiz für Volatilität, wenn auch das momentane Überschreiten der Mindesthaltbarkeit nicht zwangsläufig die Unbrauchbarkeit bedeuten muss.
• POST-Daten zusätzlich zur URL führen in aller Regel dazu, dass derartige Seiten nicht wiederholbar abgerufen werden können, und werden üblicherweise nicht im Cache abgelegt. Dies wäre auch recht gefährlich, weil derartige Informationen oft den Inhalt der Zielseite verändern und eine notwendige Bestätigung an den Server nicht abgeschickt werden würde.
• Wird in der URL am ? eine Query erkannt (etwa bei einer Datenbankabfrage), hatten Algorithmen ursprünglich von der Speicherung abgesehen, weil durch Kombination der Abfrageparameter viele unterschiedliche URL ohne eine Wiederverwendung zustande kamen. Zunehmend werden aber von CMS alle Seiten statisch in diesem URL-Format präsentiert, so dass diese Annahme nicht mehr verlässlich ist.

„Verfallsdatum“

Die Ressource ist mit einem Ablaufdatum (Zeitpunkt) versehen oder aber einem Haltbarkeitszeitraum nach Abruf (etwa: „drei Tage“), aus dem der Zeitpunkt der Ungültigkeit berechnet werden kann.^[4]

• Felder:

• Expires:^[5] mit einem konkreten Zeitpunkt und
• Cache-Control: max-age=^[6] in Sekunden als relative Angabe^[7]

Beispiel: Wetterbericht; immer gültig für die folgenden 15 Minuten.

• Die Ungültigkeit der Ressource bewirkt aber nicht zwangsläufig die Löschung aus dem Cache, sondern lediglich eine Überprüfung der Gültigkeit, was zu einer Verlängerung der Gültigkeitsperiode bei unverändertem Inhalt führen kann.
• Liegt der als Expires angegebene Zeitpunkt im Moment der Abfrage bereits in der Vergangenheit, kann diese Version nicht in den Cache aufgenommen werden; Angaben zu dieser URL wären zu löschen.
• Fehlen Angaben des Servers zur Gültigkeitsperiode, kann aus dem Zeitpunkt der letzten Änderung, notfalls aus dem durch das Caching aufgezeichneten Verhalten geschlossen werden, ob sich die Ressource häufig ändert oder konstant ist: Wurde zuletzt vor drei Jahren verändert, ist die Ressource wohl recht stabil; ist sie gerade eine Viertelstunde alt oder hat sie sich während des letzten Tages zweimal geändert, wäre sie kurzfristig auf Aktualität zu überprüfen. Wie genau das Cache Management adäquat mit fehlenden Meta-Informationen umgeht, bleibt der Intelligenz der Programmierer überlassen. Plump und Zeit wie Netzwerkkapazität fressend wäre es, bei fehlenden Angaben eine große Datei jedes Mal neu vom Webserver abzurufen.
• In der Benutzerkonfiguration könnte ein Höchstalter angegeben worden sein, etwa zwei Wochen.

No-Cache^[8]

Eine Ressource gibt bekannt, dass sie nicht im Cache gehalten werden soll und bei jedem Seitenaufbau frisch vom Server abzurufen ist.

Felder:

• Cache-Control: no-cache
• Cache-Control: max-age=0

Traditionell werden diese beiden Felder gleichzeitig übermittelt, obwohl redundant – in der Hoffnung, dass der Browser wenigstens eines davon verstehen möge. Kombiniert wird das gern noch mit dem „Verfallsdatum“ 1. Januar 1970; auch dies hätte die gleiche Wirkung.

Beispiel: Börsenkurse; ändern sich mit jeder Sekunde.

Präziser: Bei Cache-Control: no-cache wäre es einem Browser erlaubt, die Ressource im Cache zu halten; er müsste sich aber vor jedem Zugriff durch Rückfrage beim Server vergewissern, dass sie noch aktuell wäre. Es ist in das freie Ermessen der Browser-Implementierer gestellt, dies so zu handhaben oder solch absehbar schnell veraltende Informationen gar nicht erst in den Cache aufzunehmen.

In der Wirkung beim Leser und in der vom Anbieter gewünschten Darstellung unterscheidet sich das nicht.

Versionsvergleich

Der Browser vermutet anhand eines Ablaufzeitpunkts, dass die momentan im Cache vorhandene Ressource veraltet sein könnte (englisch: stale ‚abgestanden, schal‘). Es gibt dann zwei Möglichkeiten:

• Die kurze HEAD-Information der Ressource beim Server abfragen (zunächst ohne den vollständigen Inhalt), das Ergebnis selbst auswerten und dann ggf. auch den Inhalt abfordern (GET).
• Die bekannten Versionsinformationen (Last-Modified/ETag) an den Server senden. Der Server antwortet entweder mit dem HTTP-Statuscode 304 Not Modified (die Version ist noch gültig) oder sendet eine neue Version (200 OK) – schlimmstenfalls nunmehr 404 Not Found.

Invalidation^[9]

Wird zu einer URL später eine der relativ selten vorkommenden POST-, PUT- oder DELETE-HTTP-Request-Methode festgestellt, wie sie bei Formularen oder WebDAV benutzt werden, müsste der Eintrag zu dieser URL aus dem Cache gelöscht werden, weil dadurch diese Ressource auf dem Server verändert worden sein kann.

No-Store^[10]

Standardmäßig wird jede erfolgreich übertragene Ressource als einzelne Datei auf der Festplatte abgelegt. Bricht die Übertragung zusammen oder stürzt gar der Rechner ab, kann der Seitenaufbau mit den Zwischenergebnissen fortgesetzt werden. In den Anfangsjahren der Browser war der reale Kernspeicher auch begrenzt, die Netzwerke langsam, so dass sich diese Vorgehensweise kaum vermeiden ließ. Das gilt für alle Ressourcen der aktuell dargestellten Seiten, unabhängig von der Verwendung eines Cache.

• Nach Abschluss der Seitendarstellung werden diejenigen Dateien, bei denen eine spätere Wiederverwendung möglich erscheint, in die Datenstruktur des Cache übernommen; alle anderen Dateien werden als temporär markiert und zu gegebener Zeit gelöscht.
• Bei besonders sensiblen Ressourcen (etwa Finanztransaktionen, Kontodaten) könnten Spuren auf der Festplatte zurückbleiben; etwa weil das „Löschen“ einer Datei nur die Entfernung aus dem sichtbaren Dateisystem bedeutet, nicht aber sofort das physische Überschreiben. Stürzt der Browser oder der Rechner ab, könnten Dateien zurückbleiben; auch nach scheinbarer Löschung könnte die physische Festplatte noch sensible Informationen enthalten, die bei Anmeldung auf dem fraglichen Benutzerkonto noch lesbar wären.
• Mit Cache-Control: no-store markierte Ressourcen soll ein Browser nicht auf die Festplatte zwischenspeichern, sondern nur volatil im Kernspeicher halten.
• Das Konzept hat allerdings eine Lücke: Nur selten bietet das Betriebssystem einer Anwendung die Möglichkeit, Kernspeicher anzufordern, der zugesichert nicht in die Speicherungsauslagerungsdatei auf der Festplatte ausgelagert wird.

Der Cache eines Benutzers lässt Rückschlüsse zu, welche Themen aufgerufen werden.

• Ein Benutzer sollte auf seinem Rechner einen individualisierten Cache verwenden; für jedes Benutzerkonto also ein eigener und vor dem Lesen durch andere Benutzer geschützter Bereich.
  • Etwa 2000/2005 wurden die bis dahin gebräuchlichen zentralen Cache-Verzeichnisse, die von allen Benutzern eines PC gemeinsam benutzt wurden und auch von jedem Benutzer gelesen werden konnten, durch individualisierte Cache ersetzt, deren Zugriffsrechte auf den beim Betriebssystem angemeldeten Benutzer begrenzt sind, und die auch jeweils auf ein Benutzerprofil des Browsers beschränkt sind.
  • Die meisten Browser kennen einen „Privat-Modus“. Hierbei wird unter anderem eine zusätzliche Cache-Datenstruktur aufgebaut, die alle jetzt abgerufenen Ressourcen aufnimmt. Der „normale“ Cache kann ggf. parallel lesend benutzt werden, es dürfen dort aber keine Informationen geschrieben werden. Mit Ende des Privat-Modus wird der zusätzliche Cache gelöscht.
• Proxy-Server, über die offen kommuniziert wird, speichern für alle Benutzer des Netzwerks die von ihnen genutzten Seiten und die Zugriffsstatistik.
• Über HTTPS abgerufene URL lassen sich auf Proxy-Servern nicht speichern, die zugehörigen Inhalte und sogar URL-Pfade sind verschlüsselt.
  • HTTPS hat hingegen keinen Einfluss auf das Caching beim anfordernden Einzelbenutzer, der die URL und entschlüsselten Inhalte ja kennt. Allerdings gibt es bei manchen Browsern eine individuelle Konfigurationseinstellung, nach der über HTTPS abgerufene Informationen nicht im Cache abgelegt werden sollen. Durch die starke Verbreitung von HTTPS auch für drahtlose Verbindungen lässt die Verwendung dieses Protokolls aber kaum noch einen Rückschluss auf einen besonderen Geheimhaltungsbedarf der damit übertragenen Seiten zu.
• Die Server-Antwort Cache-Control: private soll bewirken, dass diese Ressource nur in dem individualisierten Cache eines Benutzers gespeichert werden darf, nicht aber auf Proxy-Servern oder geteiltem Browser-Cache.

Einige Felder richten sich speziell an Proxy-Server, also beliebige Zwischenstationen zwischen dem Browser und dem Server mit dem eigentlichen Ursprung der Daten. Die Zwischenstellen können auf „geteiltem Cache“ für alle Teilnehmer des Netzwerks (oder Benutzer des Computers) häufiger abgefragte Ressourcen bereithalten.

Felder in der Ressource

• Cache-Control: s-maxage=nSeconds^[11]
  Wie max-age, jedoch nur auf geteiltem (“s”=“shared”) Cache.
• Cache-Control: private
  Nicht auf geteiltem Cache speichern.
• Cache-Control: public
  Explizit freigegeben zur Speicherung auf geteiltem Cache.

Ein Browser kann in seiner Anfrage übermitteln

Pragma: no-cache
Ein unterwegs angetroffener Proxy-Server soll die Anfrage zum Ursprung durchreichen und nicht aus seinem Cache beantworten. Auch wird empfohlen, die Ressource zu dieser URL bereits als überholt (Mindesthaltbarkeit abgelaufen) zu markieren, da offenkundig Zweifel an der Aktualität aufgetreten sind.

Zusammengefasst beeinflussen vor allem folgende Felder des HTTP das Caching – falls vom Webserver geliefert oder die Grundlage geschaffen wurde:

Webserver

• Last-Modified: timestamp
• ETag: version
• Expires: timestamp
• Cache-Control:
  • max-age
  • must-revalidate
  • no-cache
  • no-store
  • private
  • public
  • s-maxage
  • … und weitere
• Vary

Browser-Anfrage

• If-Modified-Since   für Last-Modified
• If-None-Match   für ETag
• Pragma: no-cache   Proxy-Server umgehen

Die gleichen Informationen, die ein Webserver zusätzlich zum Inhalt übermittelt, können auch in ein HTML-Dokument integriert werden^[12] und die Standard-Angaben des Servers ggf. überschreiben:

   <meta http-equiv="Last-Modified" content="..." />

• Anleitung zum Leeren des Caches gängiger Browser. browser-cache.de
• Anleitung zum Leeren des Caches gängiger Browser. clear-my-browser-cache.com
• RFC 2616 – HTTP 1.1. 1999 (insbesondere Abschnitte 13 und 14; grundlegende Techniken für die Browser-Entwicklung, englisch).
• Hilfe:Cache – zur Caching-Problematik in der Wikipedia
• Cache-Control: immutable

1. ↑ RFC 2068 – Hypertext Transfer Protocol – HTTP/1.1. Januar 1997 (englisch).
2. ↑ RFC 2616 – HTTP 1.1. 1999 (englisch).
3. ↑ RFC 2616 Abschnitt 14.19 (englisch).
4. ↑ RFC 2616 Abschnitt 13.2.4 (englisch).
5. ↑ RFC 2616 Abschnitt 14.21 (englisch).
6. ↑ RFC 2616 Abschnitt 14.9.3 (englisch). RFC 2616 Abschnitt 14.9.4 (englisch).
7. ↑ &max-age= – Manche Webserver senden auf einen URL-Parameter wie diesen hin in der Antwort das entsprechende Feld Cache-Control.
8. ↑ RFC 2616 Abschnitt 14.9.1 (englisch).
9. ↑ RFC 2616 Abschnitt 13.10 (englisch).
10. ↑ RFC 2616 Abschnitt 14.9.2 (englisch).
11. ↑ RFC 2616 Abschnitt 14.9.3 (englisch).
12. ↑ HTML.4