Cache-Control

Cache-Control

Copyright ┬ę imperva.com

Was ist Cache-Control?

Der Begriff Cache-Control beschreibt ein Header-Feld, das Einsatz findet, um Direktiven f├╝r Caching-Mechanismen zu beschreiben. Dies bezieht sich sowohl auf Requests (Anfragen) als auch auf Responses (Antworten). Die Caching-Direktiven sind dabei unidirektional. Eine Direktive in einem Request bedeutet nicht zwingend, dass diese Direktive in einem Response zur├╝ckkommt. Caching-Richtlinien lassen sich ├╝ber Cache-Control-Header f├╝r jede Ressource definieren.

├ťberblick und Allgemeines zum Begriff

Die Cache-Control-Anweisung erm├Âglicht eine Festlegung, wer Antworten im Cache-Speicher ablegen kann. Ebenso ist die Cache-Control-Anweisung daf├╝r ausschlaggebend, unter welchen Bedingungen und welchen Zeitraum dies geschieht. Der Cache-Control-HTTP-Header erm├Âglicht eine genaue Definition der Caching-Richtlinien f├╝r jede Ressource.

Definiert wurde dieser HTTP-Header im Zuge der Spezifikation HTTP/1.1. Er ersetzt vorherige Header wie etwa Expires. Diese bisherigen Header fanden Anwendung zur Festlegung der Caching-Richtlinien f├╝r Antworten (Responses). Da nahezu s├Ąmtliche aktuellen Browser die Cache-Control unterst├╝tzen, ist dieser Header hinreichend.

Im Idealfall sind Requests solche Anfragen, die keine Server-Kommunikation erforderlich machen. Mittels einer lokalen Kopie der Antwort ist es m├Âglich, die Netzwerklatenz auszuschalten. Auf diese Weise lassen sich Geb├╝hren, die ansonsten f├╝r die Daten├╝bertragung anfallen, umgehen. Um dies zu realisieren, erm├Âglicht die HTTP-Spezifikation dem Server die R├╝cksendung einer bestimmten Anzahl von Cache-Control-Anweisungen. Diese regeln, auf welche Weise und f├╝r welche Zeitdauer einzelne Responses von Browsern (oder anderen Cache-Speichern) zwischengespeichert werden.

Direktiven

Da Cache-Control der Beschreibung von Direktiven f├╝r die Caching-Mechanismen dient, ist eine genaue Kenntnis der Direktive von Bedeutung. Die Direktiven ber├╝cksichtigen die Schreibweise (Gro├č- und Kleinschreibung) und verf├╝gen ├╝ber optionale Argumente. Diese verwenden beispielsweise Zeichenketten mit Anf├╝hrungszeichen oder eine bestimmte Syntax. Handelt es sich um mehrere Direktiven, so werden diese durch Kommata getrennt.

Eine wichtige Direktive betrifft die Angabe, ob es sich um eine ├Âffentliche oder private Antwort handelt. Um anzugeben, dass eine Antwort cachebar ist beziehungsweise zwischengespeichert werden kann, ist sie als ├Âffentlich oder public zu kennzeichnen. Die Antwort kann in diesem Fall auch dann zwischengespeichert werden, wenn eine HTTP-Authentifizierung damit verbunden ist. Eine Kennzeichnung als ├Âffentlich ist oft nicht erforderlich, denn andere Informationen wie etwa max-age geben bereits an, dass es sich um eine cachebare Antwort handelt.

Davon zu unterscheiden sind private Antworten. Diese lassen sich im Browser zwischenspeichern, sind jedoch in der Regel nur f├╝r einen bestimmten Anwender vorgesehen. Daf├╝r d├╝rfen sie nicht dazwischen in einem anderen Cache abgelegt werden. Somit l├Ąsst sich eine HTML-Seite, die private Informationen beinhaltet nur vom Browser des Anwenders zwischenspeichern und nicht von einem CDN.

Die Direktive no-cache veranlasst Caches dazu, die Anfrage an den urspr├╝nglichen Server zu stellen. Auf diese Weise l├Ąsst sich die G├╝ltigkeit validieren, bevor es zur Freigabe einer zwischengespeicherten Kopie kommt. Mit der Direktive only-if-cached l├Ąsst sich angeben, dass zun├Ąchst keine neuen Informationen abgerufen werden. Der Client nimmt keinen Kontakt zum urspr├╝nglichen Server auf, um zu ├╝berpr├╝fen, ob es eine neuere Kopie vorliegt. Stattdessen erh├Ąlt er lediglich eine zwischengespeicherte Response.

Die Direktive der Bezeichnung max-age= definiert die maximale Zeitspanne, in der eine Response als aktuell eingestuft wird. Die Angabe erfolgt in Sekunden. Sie bedeutet in der Praxis den Zeitraum, innerhalb dessen die abgerufene Response wiederverwendet werden kann. Handelt es sich etwa um einen max-age=60, so gilt die Antwort 60 Sekunden lang als aktuell, darf zwischengespeichert und wiederverwendet werden. Diese Direktive verh├Ąlt sich relativ zum Zeitpunkt der Requests und verh├Ąlt sich damit anders als etwa Expires.

s-maxage= hat Bezug zu ├Âffentlichen, geteilten Caches, die beispielsweise von Proxy-Servern stammten. Private Caches ignorieren diese Direktive. Ihre Aufgabe ist es, den max-age (oder den Expires-Header) zu ├╝berschreiben.

Der max-stale[=] zeigt an, dass ein Client eine Antwort auch dann akzeptiert, wenn diese bereits ihre Ablaufzeit ├╝berschritten kann. Hier haben Anwender auch die M├Âglichkeit, anzugeben, welche Zeit in Sekunden eine Antwort maximal abgelaufen sein darf, um noch akzeptiert zu werden.

Die Direktive min-fresh= zeigt an, dass Clients Antworten erwarten, die minimal noch f├╝r die hier in Sekunden angegebene Zeit aktuell ist.

Mittels stale-while-revalidate= l├Ąsst sich angeben, dass Clients dann bereit sind, eine bereits abgelaufene Antwort noch zu akzeptieren, wenn im Hintergrund noch eine Pr├╝fung auf eine Aktualisierung erfolgt. Mit dem zweiten Wert wird angegeben, wie lange der Client diese abgelaufene Antwort noch zu akzeptieren bereit ist.

Die Direktive must-revalidate sieht vor, dass der Cache den Status einer abgelaufenen Antwort ├╝berpr├╝fen muss, bevor diese Verwendung finden kann. Hierbei sollten keine abgelaufenen Ressourcen angewandt werden.

├ähnlich funktioniert proxy-revalidate, jedoch bezieht sich dies auf ├Âffentliche, geteilte Caches, beispielsweise Proxy-Server. Private Caches ignorieren diese Direktive.

Mit immutable l├Ąsst sich angeben, dass es zu keiner ├änderung des Response-K├Ârpers im Verlaufe der Zeit kommt. Handelt es sich um eine nicht abgelaufene Ressource, so liegt sie auf dem Server in unver├Ąnderter Form vor. Daher sollten Clients keine bedingte Revalidierung zur ├ťberpr├╝fung auf Aktualisierung schicken, beispielsweise in Form von If-None-Match. Dies gilt auch, wenn Anwender die Seite nicht explizit aktualisieren. In manchen Browsern wie Firefox wird die Direktive immutable nur im Falle von Transaktionen mit https:// ber├╝cksichtigt.

Mit no-cache l├Ąsst sich angeben, dass sich eine zur├╝ckgesendete Response nicht ohne Weiteres zur Beantwortung eines anschlie├čenden Requests an die gleiche URL einsetzen l├Ąsst. Voraussetzung ist eine Nachfrage beim Server, ob es zu einer ├änderung der Antwort kam. Handelt es sich um ein ordnungsgem├Ą├čes Validierungs-Token, so f├╝hrt no-cache einen Umlauf zur Validierung der gecachten Antwort durch. Hat sich an der Ressource nichts ge├Ąndert, so wird der Download vermieden.

No-store untersagt den Browsern sowie den zwischengeschalteten Cache-Speichern die Speicherung irgendeiner Version der zur├╝ckgesendeten Response. Bei jeder Anforderung einer Ressource durch einen Anwender kommt es daher zu einer neuen Anfrage an den Server. In jedem Falle kommt es dann zum Download einer vollst├Ąndigen Antwort.

Mittels no-transform wird verhindert, dass eine Konvertierung oder Transformation einer Ressource ausgef├╝hrt wird. Verschiedene Header wie Content-Range oder Content-Encoding erfahren hierbei keine Ver├Ąnderung durch einen Proxy-Server. Proxy-Server k├Ânnten etwa Konvertierungen zwischen unterschiedlichen Formaten (beispielsweise Bilddateien) vornehmen. Dies dient der Einsparung des Datenverkehrs zur Beschleunigung der Verbindung oder einer Ersparnis von Speicherplatz. No-transform unterbindet diese Aktivit├Ąten.

Cache-Control und seine Richtlinien

Eine Herausforderung besteht f├╝r Anwender darin, die f├╝r sie bestm├Âgliche Caching-Direktiven f├╝r bestimmte Ressourcen zu bestimmen. Empfehlenswert ist es, m├Âglichst viele Antworten ├╝ber einen maximalen Zeitraum auf einem Client zwischenzuspeichern. F├╝r eine gelingende Revalidierung ist es vorteilhaft, Validierungs-Token f├╝r jede Response anzugeben.

Auf den beliebtesten Internetseiten lassen sich die H├Ąlfte der heruntergeladenen Responses im Browser zwischenspeichern. Dies geht insbesondere bei wiederholtem Aufruf mit deutlicher Ressourcen-Ersparnis einher. Wie viel sich de facto zwischenspeichern l├Ąsst, h├Ąngt von der jeweiligen Webseite ab. Manche erm├Âglichen Einsparungen von 80 Prozent, w├Ąhrend andere aufgrund zahlreicher privater Daten kaum M├Âglichkeiten f├╝r den Cache-Speicher bieten.


Sie haben noch Fragen?

Kontaktieren Sie uns

Kostenloser SEO-Check der OSG


Weitere Inhalte