Sicherheitswarnung: Bitte keine Version älter als 1.11 verwenden!

Die Behandlung bedingter HTTP-Zugriffe durch gzip_cnc

Lokale Speicherung von HTTP-Inhalten

Der erste Besuch eines Browsers auf einer Website beginnt damit, den Inhalt entsprechender Dateien von diesem Server anzufordern. Aber bereits während dieses Besuchs - und ebenso bei nachfolgenden Besuchen - wird der Browser Inhalte benötigen, die er bereits vorher mindestens einmal angefordert hat.

Wenn der Browser davon ausgehen dürfte, daß sich der Inhalt einer solchen Datei zwischen zwei Anforderungen nicht geändert hat, dann könnte er diesen Inhalt auf dem lokalen Rechner zwischenspeichern, etwa

und immer dann, wenn ein solcher Inhalt benötigt wird, einfach seine lokale Kopie verwenden.

Dabei steht dem Browser allerdings nur eine begrenzte (normalerweise im Browser konfigurierbare) Menge an Speicherplatz für seinen Zwischenspeicher (Cache) zur Verfügung - und zudem ist der Aufwand, eine Information aus den lokal gespeicherten Daten herauszusuchen, abhängig von der Menge derartig gespeicherter Informationen: Ein voller Zwischenspeicher ist langsamer als ein leerer. Daher ist es weder möglich noch sinnvoll, unbegrenzt viele Seiten lokal zu speichern; sinnvollerweise wird der Browser die ältesten bzw. am längsten nicht mehr verwendeten Inhalte wieder freigeben, um neuere bzw. aktuell benötigte Dateien zu speichern.

In jedem Fall aber ist der Zugriff auf lokal gespeicherte Daten natürlich erheblich schneller möglich als eine Anforderung der Daten von einem entfernten Server: Jede eingesparte Anforderung macht das Surfen schneller.

Zudem ist es durchaus üblich, daß bestimmte Dateien immer wieder benötigt werden, weil sie Bestandteile vieler verschiedener Seiten sind. Typische Beispiele hierfür sind etwa

welche häufig in separaten Dateien gespeichert und in mehreren HTML-Seiten über die angegebenen HTML-Tags nur eingebunden werden, um ein einheitliches Aussehen bzw. Verhalten 'verwandter' Seiten zu ermöglichen. Bei derartig oft verwendeten Dateien lohnt sich das Zwischenspeichern also besonders.

Allgemein betrachtet kann man also feststellen, daß sich die lokale Speicherung bereits empfangener Informationen lohnt.

Die Sache hat nur ein Problem: Was passiert, wenn sich der Inhalt einer solchen Datei seit der letzten Anforderung geändert hat? In diesem Falle wäre die dem Anwender von seinem Browser angezeigte Information schlicht und einfach falsch. Und je nach der Art dieser Information kann das mehr oder weniger wichtig sein - bei einer geschäftlichen Transaktion, etwa beim Online-Banking, wäre eine falsche Information nicht akzeptabel.

Entität eines Seiteninhalts

Zu einem bestimmten Zeitpunkt mag ein Seiteninhalt durch die Adresse seiner Anforderung, den URL, eindeutig bestimmt sein - wenigstens in den meisten Fällen. Diejenigen Fälle, in denen nicht einmal dies der Fall ist (HTTP-Methode POST, serverseitige bedingte Erzeugung des Inhalts in Abhängigkeit von Inhalten der Anforderung wie Browsername, Cookies usw.) seien an dieser Stelle bewußt ausgeklammert, um die Beschreibung zu vereinfachen.

Da sich der Inhalt einer Seite im Laufe der Zeit aber definitiv ändern kann, sind für die eindeutige Bestimmung eines Seiteninhalts zusätzliche Informationen erforderlich.

Eine dieser Informationen ist der Zeitpunkt der Erzeugung eines Inhalts. Der Server sollte zusammen mit dem Ergebnis den HTTP-Header Last-Modified: senden, wann immer er dazu in der Lage ist. Dieser kann beispielsweise das Datum der letzten Änderung der entsprechenden Datei auf dem Server beschreiben. Die Idee dabei ist, daß der Browser zwei Versionen von Inhalten derselben Anforderung, die ein übereinstimmendes Datum ihrer letzten Änderung aufweisen, als identisch behandeln soll. Dieses Datum muß in einem Format angegeben werden, welches durch den RFC 1123 definiert ist - was bedeutet, daß dieses Datum maximal sekundengenau angegeben werden kann.

In der Realität mag diese Logik heutzutage noch ausreichen. In bestimmten Umgebungen, nämlich bei sehr schnellen Servern und sehr schnellen Netzverbindungen, ist eine sekundengenaue Angabe möglicherweise zu wenig.

Deshalb erlaubt die Spezifikation von HTTP/1.1 einem HTTP-Server, einer bestimmten Variante eines Inhalts, einer sogenannten Entität, eine entsprechende Markierung (entity tag) zu geben. Der Wert dieser Markierung kann vom HTTP-Server als Inhalt des HTTP-Headers ETag: an den Browser ausgeliefert werden.

Der Inhalt dieser Markierung unterliegt keiner Einschränkung - der Server darf dort angeben, was er will. Diese Markierung kann also beispielsweise aus einer Prüfsumme über den Seiteninhalt bestehen, oder aus einer sehr viel genaueren Angabe über den Erzeugungszeitpunkt, oder aus eine Kombination von beidem ...

Der Browser muß den Inhalt dieser Markierung auch gar nicht verstehen. Alles, was den Browser interessiert, ist, ob die ihm vorliegende Entität mit derjenigen, die ein Server auf eine nun eintreffende erneute Anforderung ausliefern würde, exakt übereinstimmt.

Und da diese Entitäts-Markierung eine genauere Aussage über den Inhalt einer angeforderten Datei liefert, sollte ein zeitgemäßer Browser dieser Markierung im Zweifelsfalle den Vorrang gegenüber dem Datumswert des Last-Modified:-Headers geben.

Verbot einer Zwischenspeicherung durch den Server

Das Wissen darüber, ob eine A

Strategie bei der Verwaltung von Cache-Inhalten

In der Konfiguration eines Browsers kann der Anwender die Strategie, nach welcher der Browser die Gültigkeit des Inhalts seines Cache prüfen soll, einstellen.

Bei zeitgemäßen Browsern wie Mozilla oder dem Internet Explorer stehen ihm dabei üblicherweise die folgenden vier Möglichkeiten zur Verfügung:

Cache-Inhalt bei jedem Anzeigen der Seite prüfen

Die Einstellung "bei jedem Anzeigen der Seite prüfen" ist die langsamste - aber auch die sicherste.

Der Browser glaubt dabei dem Inhalt seines lokalen Speichers nicht, ohne zuvor den Server zu fragen, ob er diesen weiterhin verwenden darf.

Dies kostet dann natürlich jedesmal einen HTTP-Zugriff - als hätte der Browser gar keinen lokalen Speicher. Allerdings nützt der lokale Speicher trotzdem etwas - warum, das werden wir später sehen.

Cache-Inhalt nie prüfen

Die Einstellung "nie prüfen" ist die schnellste - aber auch die 'gefährlichste'.

Den Inhalt des Cache ungeprüft zu verwenden, geht natürlich viel schneller, als eine erneute Anforderung nach dieser Datei an den Server zu stellen.

Allerdings besteht dabei die Gefahr, daß der Browser veraltete Inhalte darstellt, weil er nicht mitbekommen hat, daß sich der Inhalt dieser Datei auf dem Server geändert hat.

Cache-Inhalt beim ersten Zugriff während der aktuellen Browser-Sitzung prüfen

Während der Anforderungen von HTTP-Ressourcen durch einen Browser ist es durchaus üblich, daß innerhalb kurzer Zeit dieselbe Ressource mehrfach verwendet werden soll.

In diesen Fällen darf der Browser mit einiger Berechtigung davon ausgehen, daß sich der Inhalt der Dateien nicht innerhalb kurzer Zeit ändert. Insofern ist die Strategie, den Inhalt einer solchen Datei während einer Browser-Sitzung nur "beim ersten Zugriff" zu prüfen, eine gute Wette - es ist aber keine Garantie, nicht doch veraltete Inhalte darzustellen.

Cache-Inhalt nur dann prüfen, "wenn es nötig ist"

Den mit absoluter Sicherheit kann nur der Server, der den Inhalt einer Seite geliefert hat, entscheiden, ob dieser Inhalt noch gültig ist.

Allerdings kann der Server dem Browser erlauben, für eine bestimmte Zeitdauer nicht zu fragen, also eine Aufbewahrungsdauer für den Inhalt einer Seite mit senden. Zu diesem Zweck existieren die HTTP-Header

die dem Browser jeweils ein Verfallsdatums dieses Seiteninhalts beschreiben.

Vor einer eventuellen Überprüfung des Seiteninhalts darf der Browser also prüfen,

Die Überprüfung der Gültigkeit eines Cache-Inhalts

Um

(Michael Schröpl, 2002-10-07)