HTTP Caching FAQ

Was wird im Cache gespeichert?

Der Mozilla Cache beinhaltet alle Dokumente, die via HTTP vom Benutzer heruntergeladen wurden. Dies mag sich zunächst widersprüchlich anhören. Dieses Verhalten ermöglicht jedoch das Vor- und Zurück-Navigieren, Speichern, sowie die Anzeige des Quelltextes etc. im Browser, ohne dabei zusätzliche Serveranfragen zu benötigen. Somit verbessert es auch die Offline-Nutzung von temporär gespeicherten Inhalten im Cache.

Was ist mit Dokumenten die mit "Cache-control: no-cache"  in der Kopfzeile (Header) gesendet werden?

Ja, auch "no-cache" Dokumente werden von uns aufgrund der oben genannten Gründe im Cache gespeichert.

Sorgt das nicht dafür, dass abgelaufene Inhalte bereitgestellt werden?

Nein, denn jedes Dokument, das im Mozilla Cache gespeichert wird, erhält eine Gültigkeitsdauer. Lädt Mozilla dieses Dokument für eine normale Ansicht, wird die Gültigkeit berücksichtigt. Wenn nötig, wird ein aus dem Cache zu ladendes Dokument mit dem Server abgeglichen, bevor es dem Benutzer angezeigt wird.

Wie wird die Gültigkeitsdauer berechnet (da nicht jede Serverantwort eine Gültigkeit in der Kopfzeile enthält)?

Mozilla strebt danach, RFC 2616 zu implementieren (siehe speziell Abschnitt 13 für nähere Informationen). Die folgende Antwort-Kopfzeile generiert eine stets abgelaufene Gültigkeitsdauer: "00:00:00 UTC, January 1, 1970" (Beispielwert):

Cache-control: no-cache
Cache-control: no-store
Pragma: no-cache
Expires: 0

Bemerkenswerter Weise sind die Werte "Expires: 0" und "Pragma: no-cache" technisch gesehen ungültige Werte in einer Antwort-Kopfzeile. Wenn keine dieser Angaben vorhanden ist, entspricht die Berechnung der Gültigkeitsdauer dem Algorhythmus der in RFC 2616, Abschnitt 13.2. beschrieben wird. Wir ermitteln das gegenwärtige Alter der Antwort und seine Gültigkeit basierend auf den vorhandenen Informationen.

Das gegenwärtige Alter entspricht für gewöhnlich einem Wert nahe zu Null, wird jedoch durch eine vorhandene Age Angabe in der Antwort-Kopfzeile beeinflusst, die z.b. von Proxy Caches angeben wird um die Länge der Dauer anzugeben, die sich ein Dokument bereits in ihrem Cache befindet. Der exakte Algorhythmus, der versucht Fehler bei der Zeitverschiebung zu verhindern, wird in RFC 2616, Abschnitt 13.2.3 beschrieben.

Die Gültigkeit wird basierend auf mehreren Antwort-Kopfzeilen berechnet. Wenn in der Kopfzeile der Wert "Cache-control: max-age=N" angegeben ist, entspricht die Gültigkeit des Dokumentes dem Wert N. Ist dieser Wert nicht vorhanden, was mitunter sehr oft der Fall ist, wird nach einer "Expires" Angabe in der Kopfzeile gesucht. Existiert eine "Expires" Angabe, ergibt sich die Gültigkeitsdauer aus dem darin enthaltenen Wert abzüglich des in "Date" enthaltenen Wertes. Solltes sich letztlich keine "Expires" Angabe in der Antwort-Kopfzeile befinden, suchen wir nach einem "Last-Modified" Wert. Ist dieser Wert vorhanden, entspricht die Gültigkeitsdauer des Caches dem Wert "Date" abzüglich des Wertes "Last-Modified" geteilt durch 10. Dies ist die vereinfachte Darstellung des heuristischen Algorhythmus, der in Abschnitt 13.2.4 des RFC 2616 vorgeschlagen wird. 

Die Gültigkeitsdauer berechnet sich somit folgendermaßen:

expirationTime = responseTime + freshnessLifetime - currentAge

Wobei responseTime dem Zeitwert entspricht, zu dem der Browser die Antwort erhalten hat.

Gibt es weitere Faktoren, welche die Revalidation beinflussen?

Die Revalidation wird ausgelöst, sobald ein User die Seite neu lädt (Refresh-Button). Ebenso wird sie beim normalen browsen ausgelöst, wenn in der Antwort-Kopfzeile der Wert "Cache-control: must-revalidate" enthalten ist. Ein weiterer Faktor sind die Einstellungen des Cache-Management im Bereich Erweitert->Netzwerk der Firefox Einstellungen. Hier kann als Option gewählt werden, dass Dokumente bei jedem Laden neu validiert werden ("Nachfragen, wenn Websites Daten für die Verwendung im Offline-Modus speichern möchten").

Wie funktioniert die Cache Valdiation?

Sobald die Gültigkeit eines Dokumentes im Cache abgelaufen ist, wird es entweder revalidiert oder gänzlich neu vom Server angefordert. Eine Validation kann nur dann angwendet werden, wenn der Server entweder eine starke Valdiation (strong validation) oder eine schwache Valdiation (weak validation) ermöglicht. Cache Validatoren werden im Abschnitt 13.3.2 des RFC 2616 beschrieben.

Der "ETag" Wert in der Antwort-Kopfzeile ist ein Wert, der nicht einsehbar für den User Agent ist (opaque-to-the-useragent) und als starker Validation genutzt werden kann (strong validator). Ist der "ETag" Wert in der Antwort-Kopfzeile vorhanden, kann der Browser einen "If-None-Match" Wert in der Antwort-Kopfzeile ausgeben, um das Dokument im Cache zu validieren.

Der "Last-Modified" Wert in der Antwort-Kopfzeile kann als schwacher Validator (weak validator) genutzt werden. Er wird als schwach eingestuft, da er nur eine 1-Sekunden-Lösung ermöglicht. Wenn der "Last-Modified" Wert in der Antwort-Kopfzeile enthalten ist, kann der Browser einen "If-Modified-Since" Wert in der Antwort-Kopfzeile ausgeben, um das Dokument im Cache zu validieren.

Sobald eine Validierungs-Anfrage gestellt wurde, kann der Server diese entweder ignorieren und mit einem normalen 200 OK Wert antworten, oder aber einen 304 Not Modified Wert zurückgeben um den Browser anzuweisen, die im Cache befindliche Kopie des Dokumentes zu verwenden. Letzere kann ebenfalls Werte in der Antwort-Kopfzeile enthalten, welche die Gültigkeit des Dokumentes im Cache aktualisieren.

Was ist mit...?

Ich beabsichtige, diese Dokumentation in Zukunft zu erweitern. Fühlen Sie sich frei, mir eine E-Mail mit Ihren Fragen oder Kommentaren zu schreiben.