Browser-Cache

Browser-Cache [ˈbɹaʊ̯zə(ɹ) kæʃ] ist ein Puffer-Speicher des Webbrowsers, in dem bereits abgerufene Ressourcen (z. B. Texte oder Bilder) auf dem Rechner des Benutzers (lokal) als Kopie aufbewahrt werden. Wird eine Ressource später erneut benötigt, ist sie aus dem Cache schneller abrufbar, als wenn sie erneut aus dem World Wide Web heruntergeladen werden müsste.

Jedes Mal, wenn für die Darstellung einer Seite die Inhalte zu einer URL benötigt werden, wird zuerst im Cache nachgesehen, ob diese bereits vorhanden sind.

Vorteilhaft ist, dass Netzwerkverkehr und die Zeit zum Herunterladen aller Bestandteile einer Webseite stark reduziert werden. Nachteilig ist, dass die im Cache gespeicherten Daten veraltet sein können, wenn die Webseite zwischenzeitlich aktualisiert wurde.

Einsatzgebiete

„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.

Benutzerkontrolle

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.

Cache-Verwaltung

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 und 1999 in RFC 2616 gegeben, müssen aber nicht vollständig umgesetzt sein.

Webserver

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.

Versionsidentifikation

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

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

Methoden

Folgende Methoden stehen zur Verfügung:

• 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.

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.

Sicherheitsaspekte

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.

Proxy-Server

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.

HTTP-Caching

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

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

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

Weblinks

• 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

Einzelnachweise und Anmerkungen

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