HTTP: Cachen mit Last-Modified und If-Modified-Since

Das Cachen per Last-Modified-Header ist das älteste Cacheverfahren, als Ergänzung gibt es den Expires-Header

Das Cachen über den Response-Header Last-Modified ist das älteste Cachverfahren. Es funktioniert wie folgt: Beim ersten Request auf die Seite sendet der Server den Header Last-Modified mit einem bestimmten Datum und Uhrzeit (siehe weiter unten). Der Client (Browser, UserAgent) speichert daraufhin die Seite in seinem Cache mit dem dazugehörigen Zeitstempel. Bei einem Folgerequest sendet der Client diesen per Last-Modified bekommenen Zeitstempel in einem Request-Header If-Modified-Since. Wenn der Server eine Übereinstimmung feststellt, sendet er den Status 304 Not Modified und hierzu keinen Content.

Stimmen Last-Modified und If-Modified-Since nicht überein, wird Status 200 Ok gesendet und die Response im HTTP-Message-Body ausgeliefert.

Response-Header Last-Modifed

Beim Laden der Seite hat der Server einen Header Last-Modified: Thu, 25 Apr 2024 19:57:39 GMT gesendet. Ein Klick auf eine der untenstehenden Schaltflächen löst einen Folge-Request zum Server aus. Anhand der geklickten Schaltfläche:

[Request mit If-Modified-Since]
sendet der Client den Requestheader If-Modified-Since: Thu, 25 Apr 2024 19:57:39 GMT
[Request ohne If-Modified-Since]
erfolgt der Request ohne diesen Requestheader.

Das Ergbnis, also den HTTP-Status der Response und die Response selbst sehen Sie dann untenstehend.

Request an Server
HTTP-Status:
HTTP-Response:

Serverseitiger Code hinter CGI/1.1

Alles was zu tun ist, einen der Aufgabe entsprechenden Last-Modified-Header zu senden. Nicht notwendig ist es, den Vergleich zwischen Last-Modified und If-Modified-Since in $ENV{HTTP_IF_MODIFIED_SINCE} über die CGI-Schnittstelle hinweg zu programmieren, weil der Webserver selbst vergleicht. Es ist also egal, ob dann serverseitig (Perl, PHP) noch ein Content generiert wurde oder nicht, er wird vom Webserver nicht ausgeliefert in dem Moment wenn der Webserver entschieden hat, einen Status 304 zu senden.

Response-Header Expires

Dieser Header ist optional. Er kann vom Browser insofern herangezogen werden, als daß der Browser die Seite gar nicht erst anfordert wenn die Zeit für die Seite noch nicht abgelaufen ist, was der Browser anhand des Expires-Datum infolge Vergleich mit der Systemzeit erkennt. Der Expires-Header ermöglicht also dem Browser, die Zeiten zu vergleichen.

Tipp: Betrachte den Expires-Header als eine sinnvolle Ergänzung zum Header Last-Modified und stimme die Zeitstrings dieser beiden Header aufeinander ab.

Apache-Modul mod_expires

Das Modul veranlasst den Apache-Webserver zum Setzen eines Expires-Response-Header zuzüglich des Headers Cache-Control (max-age) für Dateien die der Webserver selbst ausliefert. Diesbezüglich konfigurierte Zeiten werden bei jedem Request neu berechnet, einschließlich der Angabe max-age für den Header Cache-Control. Erhält der Browser eine Datei die anhand dieser Header noch nicht abgelaufen ist, lädt er diese vollständig aus seinem Cache ohne einen erneuten Request zum Server abzusetzen. Das veringert die Serverlast sehr wirksam. Beispiel einer Anwendung:

ExpiresActive On
ExpiresByType application/javascript A86400

Erläuterung: Das A vor der Zeitangabe steht für Access. Obenstehende Konfiguration erklärt also jede JavaScript-Datei bei jedem Abruf (Access) für genau einen Tag gültig. Weiteres siehe Apache-Dokumentation.


Datenschutzerklärung: Diese Seite dient rein privaten Zwecken. Auf den für diese Domäne installierten Seiten werden grundsätzlich keine personenbezogenen Daten erhoben. Das Loggen der Zugriffe mit Ihrer Remote Adresse erfolgt beim Provider soweit das technisch erforderlich ist. s​os­@rolf­rost.de.