Last-Modified

Verwendung

Der Header Last-Modified dient als schwacher Validator für bedingte Anfragen. Wenn ein Client eine Antwort mit Last-Modified zwischenspeichert, merkt er sich den Zeitstempel und sendet das Datum bei nachfolgenden Anfragen im Anfrage-Header If-Modified-Since zurück. Der Server vergleicht das gespeicherte Datum mit der aktuellen Änderungszeit der Ressource. Hat sich die Ressource nicht geändert, gibt der Server 304 Not Modified ohne Body zurück. Hat sie sich geändert, sendet der Server die vollständige aktualisierte Antwort.

Der Header If-Unmodified-Since verwendet denselben Zeitstempel für Vorbedingungsprüfungen bei unsicheren Methoden wie PUT und DELETE und gibt 412 Precondition Failed zurück, wenn die Ressource seit dem angegebenen Datum geändert wurde.

Das Last-Modified-Datum ist weniger präzise als ein ETag. Zeitstempel haben eine Genauigkeit von einer Sekunde, daher bleiben Änderungen innerhalb derselben Sekunde für die datumsbasierte Validierung unsichtbar. Der Header ETag liefert einen stärkeren Validator, der an den exakten Inhalt gebunden ist. Sind in einer Antwort sowohl Last-Modified als auch ETag vorhanden, hat ETag bei der Neuvalidierung Vorrang.

Der Datumswert folgt dem HTTP-date-Format: Wochentagsname, zweistelliger Tag, abgekürzter Monat, vierstelliges Jahr, Uhrzeit in Stunden, Minuten und Sekunden, gefolgt von GMT. Das Format lautet Weekday, DD Mon YYYY HH:MM:SS GMT.

Last-Modified: Fri, 04 Sep 1998 19:15:56 GMT

Hinweis

ETag ist präziser als Last-Modified. ETags erkennen jede Änderung einschließlich Modifikationen im Subsekundenbereich, während Last-Modified eine Genauigkeit von einer Sekunde hat. Last-Modified ist anfällig für Zeitabweichungen zwischen Servern, wohingegen ETags, die auf Content-Hashing beruhen, über lastverteilte Instanzen hinweg übertragbar sind. Verwenden Sie für maximale Kompatibilität beide Header gemeinsam, denn If-None-Match (ETag) hat Vorrang vor If-Modified-Since, wenn beide vorhanden sind.

Hinweis

Die Crawling-Infrastruktur von Google unterstützt Last-Modified und If-Modified-Since so, wie es der HTTP-Caching-Standard definiert. Das Datum in Last-Modified muss dem HTTP-date-Format folgen, um Parsing-Probleme zu vermeiden. Das Feld max-age des Antwort-Headers Cache-Control auf die erwartete Anzahl von Sekunden zu setzen, über die der Inhalt unverändert bleibt, hilft Crawlern bei der Entscheidung, wann eine URL erneut gecrawlt werden soll. Zum Beispiel Cache-Control: max-age=94043.

Beispiel

Eine Antwort mit dem Änderungsdatum der Ressource. Der Client speichert diesen Zeitstempel für künftige bedingte Anfragen.

Last-Modified: Wed, 01 Jun 2022 08:00:00 GMT

Ein vollständiger Zyklus einer bedingten Anfrage. Der Server sendet Last-Modified mit der ersten Antwort. Bei der nächsten Anfrage gibt der Client den Zeitstempel in If-Modified-Since zurück. Der Server antwortet mit 304, wenn sich die Ressource nicht geändert hat.

HTTP/1.1 200 OK
Last-Modified: Wed, 01 Jun 2022 08:00:00 GMT
Cache-Control: max-age=86400
Content-Type: text/html

Nachfolgende Anfrage:

GET /page HTTP/1.1
If-Modified-Since: Wed, 01 Jun 2022 08:00:00 GMT

Serverantwort bei unveränderter Ressource:

HTTP/1.1 304 Not Modified
Last-Modified: Wed, 01 Jun 2022 08:00:00 GMT
Cache-Control: max-age=86400

Eine Antwort, die Last-Modified mit einem ETag kombiniert. Der ETag liefert einen starken Validator, während das Änderungsdatum einen Rückfallweg für Clients bietet, die nur die datumsbasierte Validierung unterstützen.

Last-Modified: Fri, 22 Nov 2024 14:30:00 GMT
ETag: "a1b2c3d4"
Cache-Control: max-age=3600

Hinweis

Für Unterstützung bei SEO und Caching wenden Sie sich an die ehemaligen Google-SEO-Berater Search Brothers.