if-modified-since


Der if-modified-since-Header ist ein Datenfeld in der HTTP-Kommunikation zwischen Server und verschiedenen Clients wie Browsern und Suchmaschinen-Crawlern. Wenn ein Client auf einen Server zugreift, der dieses Header-Datenfeld unterstützt, wird die Bedingung überprüft, ob sich die Inhalte auf dem Server seit dem letzten Zugriff durch den Client verändert haben. Wenn sich die Inhalte nicht verändert haben, sendet der Server statt der dort hinterlegten Inhalte den Status Code 304, um dem Client mitzuteilen, dass er die Inhalte nicht laden muss. Der Client kann stattdessen eine gecachte Version der Website laden: Bei Crawlern ist dies die Version, die als letztes abgerufen wurde; bei Browsern ist es die Version, die sich seit dem ersten Ladevorgang im Cache des Browser befindet. Gemäß den Google Webmaster Guidelines wird die Verwendung des if-modified-since Headers empfohlen, damit der Crawler von Google keine unnötigen Ressourcen lädt.

Allgemeine Informationen zum Thema

Im Zusammenhang mit der HTTP-Kommunikation haben Entwickler und Webmaster verschiedene Optionen, um das Verhalten von Servern und Clients zu beeinflussen. Dieses sogenannte HTTP-Caching beinhaltet verschiedene Methoden zur Steuerung von Kriterien, die die Anfragen (requests) und die Antworten (responses) betreffen.[1] Die Prinzipien, die zum Beispiel von Firefox verfolgt werden sind: Expiration und Validation.[2] Der if-modified-since und der last-modified Header sind Teil der Validation: Ein Dokument oder eine Ressource wird auf ihre aktuelle Gültigkeit hin überprüft. Auf diese Weise werden die Serveranfragen, die Datenübertragung und die Zugriffszeiten reduziert, um clientseitige Wartezeiten, serverseitige Auslastung und die genutzte Bandbreite der Datenübertragung zu regeln. Auch die verwendeten Ressourcen der Suchmaschinen-Crawler sowie der Overhead (Daten zur Verwaltung der Daten) werden reduziert.

Der if-modified-since und der last-modified Header nutzen dazu einen Zeitstempel, der vom Client abgefragt wird. Die Angabe dieses Zeitstempels ist bei allen HTTP-Protokollen obligatorisch – andernfalls kann keine konditionale Abfrage stattfinden, da keine Bedingung vorhanden wäre. Im Rahmen des Hypertext Transfer Protocol 1.1 (HTTP 1.1) stehen sogenannte HTTP ETags bereit, um die Ausgabe von Inhalten und die Zwischenspeicherung im Cache des Clients zu bestimmen. Die etags markieren eine Ressource. Apache baut den etag aus dem inode, nginx hingegen verwendet die file size und den timestamp. Die etags werden verglichen und bei einer Übereinstimmung wird der entsprechende Statuscode (zum Beispiel 304) gesendet.[3]

Funktionsweise

Das Datenfeld if-modified-since wird zusammen mit der GET-Methode verwendet: Ein Client schickt eine Anfrage mit GET-Anweisungen im Header an einen Server. Der Server antwortet, indem er die Daten zurückschickt, die angefragt wurden. Wenn das angefragte Dokument nicht verändert wurde, benötigt der Client nicht das gesamte Dokument, sondern nur den Header – es wird bei einer positiven Überprüfung des Konditionals (if-modified-since) kein Body des Dokuments mitgeschickt. Das Konditional wird überprüft, indem der mitgegebene Zeitstempel mit dem aktuellen Datum verglichen wird.[4]

  • Der Server antwortet mit einem 200 Statuscode: Das Dokument wurde verändert und muss geladen werden.
  • Der Server antwortet mit einem 304 Statuscode: Das Dokument wurde nicht verändert und muss nicht geladen werden.

Im Header einer herkömmlichen HTTP-Anfrage mit der HEAD-Methode, die lediglich die Kopfdaten eines Dokumentes abfragt, sieht dies beispielsweise so aus:[5]

HEAD /~si/index.html HTTP/1.0
 
HTTP/1.1 200 OK
Date: Thu, 23 Nov 2000 11:21:36 GMT
Server: Apache/1.3.12 ...
Expires: Fri, 24 Nov 2000 11:21:39 GMT
Content-Length: 15643
Last-Modified: Wed, 15 Nov 2000 13:11:22 GMT
Connection: close
Content-Type: text/html

In der drittletzten Zeile der Anfrage findet sich das Datenfeld last-modified zusammen mit dem Zeitstempel in standardisierter GMT-Zeit. Diese Anfrage erzeugt einen normalen 200 Statuscode mit Angabe der letzten veränderten Dateiversion. Die Inhalte werden vom Client geladen – unabhängig davon, ob es sich um einen Browser oder einen Suchmaschinen-Crawler handelt. Wichtig ist der Zeitstempel des Dokumentes, da ohne diesen keine konditionale Abfrage stattfinden kann. Er beinhaltet die Serverzeit, die durch das GMT-Format mit der Zeit des Clients synchronisiert wird.

Wird nun eine GET-Methode mit dem if-modified-since Header verwendet, sieht die Serverantwort so aus:

GET /~si/index.html HTTP/1.0
If-Modified-Since: Wed, 15 Nov 2000 13:11:23 GMT
 
HTTP/1.1 304 Not Modified
Date: Thu, 23 Nov 2000 11:23:02 GMT
Server: Apache/1.3.12 ...
Connection: close
Expires: Fri, 24 Nov 2000 11:23:06 GMT

Dass der Server einen 304er zurücksendet, ist nur möglich durch die Abfrage des Zeitstempels sowie serverseitige Unterstützung. Falls das Dokument verändert wurde, sendet der Server stattdessen einen 200 Statuscode. Ob der verwendete Server einen 304-Statuscode unterstützt, lässt sich mit einer einfachen HTTP-Anfrage mithilfe verschiedener Tools überprüfen. Unter Umständen ist ein Servicekontakt zum Provider notwendig, um herauszufinden, ob dies der Fall ist. Je nach Serverversion und eingesetzter Technologie (Unix, Apache, PHP oder verschiedene CMS wie Wordpress und Typo3) sehen diese Anfragen nicht nur unterschiedlich aus, sondern erfodern mitunter auch unterschiedliche Implementierungen. Für einige CMS stehen spezielle Plugins zur Verfügung.

Bedeutung für die Suchmaschinenoptimierung

Google empfiehlt die Verwendung des if-modified-since Headers für alle Websites.[6] Webmaster, Websitebetreiber und Entwickler sollten dieser Empfehlung folgen, wenn die Inhalte ihrer Websites sich nicht oft verändern. Wenn der Googlebot eine URL schon mal abgerufen hat, setzt er automatisch das Datenfeld if-modified-since in seine Anfragen ein. Durch die HTTP-konforme Formatierung des Datums und der Zeit nach GMT-Zeit kann der Server herausfinden, ob das Dokument bearbeitet wurde. Der Googlebot erhält daraufhin durch die Antwort vom Server die Info ob sich etwas seit seinem letzten Besuch geändert hat (200+Body vs. 304 header-only). Falls nicht, spart er sich die Zeit, um es abzurufen – und somit auch die Bandbreite bei der Datenübertragung sowie unnötigen Overhead (dies sind Metadaten, die bei der HTTP-Kommunikation anfallen). Dadurch wird zudem die Serverbelastung durch den Googlebot minimiert.[7]

Einzelnachweise

  1. Caching in HTTP w3.org Abgerufen am 02.12.2015
  2. HTTP Caching FAQ developer.mozilla.org. Abgerufen am 02.12.2015
  3. Header Field Definitions w3.org. Abgerufen am 02.12.2015
  4. HTTP Caching httpwatch.com. Abgerufen am 02.12.2015
  5. Der If-Modified-Since Header fh-wedel.de. Abgerufen am 02.12.2015
  6. Richtlinien für Webmaster support.google.com. Abgerufen am 02.12.2015
  7. Date with Googlebot, Part II: HTTP status codes and If-Modified-Since googlewebmastercentral.blogspot.de. Abgerufen am 02.12.2015

Weblinks