Was ist der Cache-Control-Header?

Cache-Control ist ein HTTP-Anfrage- oder Antwort-Header, dessen Direktiven die Speicherung, Frische, Revalidierung und Wiederverwendung durch Caches steuern. Für Browser und gemeinsam genutzte Zwischenstellen können unterschiedliche Direktiven gelten.

Cache-Control übermittelt Richtlinien durch kommagetrennte Direktiven in einer HTTP-Anfrage oder -Antwort. Frische-Direktiven bestimmen, wann eine Wiederverwendung ohne Kontakt zum Origin-Server möglich ist. Direktiven zu Speicherung, Validierung und Geltungsbereich begrenzen dagegen, was private und gemeinsam genutzte Caches speichern oder ausliefern dürfen. Antwort-Direktiven sind für einen standardkonformen Cache verbindlich, während Anfrage-Direktiven empfehlenden Charakter haben. Ein CDN kann diejenigen ignorieren, mit denen ein Client einen Zugriff auf den Origin-Server erzwingen könnte: Google Cloud CDN ignoriert beispielsweise no-cache und max-age in Anfragen. Der Header richtet sich gleichzeitig an jeden Cache auf dem Weg und kann keinen bestimmten Cache ansprechen. Deshalb definiert RFC 9213 den separaten Antwort-Header CDN-Cache-Control mit denselben Direktiven, den ein CDN-Cache mit entsprechender Unterstützung anstelle von Cache-Control verwendet.

no-cache erlaubt das Speichern einer Antwort, verlangt aber vor jeder Wiederverwendung eine erfolgreiche Validierung beim Origin-Server; no-store weist jeden privaten oder gemeinsam genutzten Cache an, die Antwort überhaupt nicht zu speichern. RFC 9111 ergänzt, dass no-store kein zuverlässiger oder ausreichender Mechanismus zum Schutz der Privatsphäre ist. Es handelt sich also um eine Caching-Anweisung und keinen Ersatz für Zugriffskontrolle.
max-age legt die Frischedauer für alle Caches fest; s-maxage überschreibt sie in gemeinsam genutzten Caches wie CDNs und wird von Browsern ignoriert. Für eine Datei, deren URL sich bei jeder Inhaltsänderung ändert, sieht das Muster von MDN eine lange Frischedauer mit max-age vor (im Beispiel ein Jahr), zusammen mit immutable. Letzteres besagt, dass die Antwort während ihrer Frischedauer nicht aktualisiert wird. s-maxage hat außerdem die Bedeutung von proxy-revalidate: Sobald die Antwort veraltet ist, muss ein gemeinsam genutzter Cache sie vor der Wiederverwendung revalidieren. Bei aktiviertem Origin Cache Control, was in den Tarifen Free, Pro und Business standardmäßig der Fall ist, liefert Cloudflare eine Antwort mit s-maxage nicht im veralteten Zustand aus. Google Cloud CDN dokumentiert dasselbe Verhalten, sodass stale-while-revalidate daneben dort keine Wirkung hat. Die von Cloudflare dokumentierte Behelfslösung ist max-age mit stale-while-revalidate und einer separaten Regel für die Edge-TTL.
private verhindert die Speicherung durch gemeinsam genutzte Caches, erlaubt aber den eigenen Cache des Browsers. Das ist daher etwas anderes, als Caching zu deaktivieren. Bei personalisierten Antworten muss diese Direktive bewusst gesetzt werden. HTTP verhindert die Speicherung einer Antwort in gemeinsam genutzten Caches von sich aus nur, wenn die Anfrage einen Header Authorization enthielt. Selbst dann hebt public, s-maxage oder must-revalidate diese Einschränkung auf. Eine Sitzung, die in einem Anfrage-Header Cookie übermittelt wird, löst keine solche Regel aus. RFC 9111 stellt fest, dass ein Antwort-Header Set-Cookie das Caching nicht verhindert. Google Cloud CDN cacht keine Antwort mit Set-Cookie. Cloudflare cacht sie bei seiner Standard-Cache-Stufe ebenfalls nicht, solange Origin Cache Control aktiviert ist. Ist es deaktiviert, kann Cloudflare die Antwort jedoch cachen und dabei den Header Set-Cookie entfernen. In beiden Fällen handelt es sich um das Verhalten des Anbieters und keine HTTP-Regel.
Eine Antwort ohne Cache-Control kann dennoch zwischengespeichert werden. RFC 9111 erlaubt einem Cache, einer heuristisch cachebaren Antwort ohne explizite Ablaufzeit eine heuristische Gültigkeitsdauer zuzuweisen. Empfohlen wird höchstens ein Bruchteil der seit Last-Modified vergangenen Zeit. CDNs wenden ihre eigene Standardgültigkeitsdauer an, wenn der Origin-Server keine sendet. Für Fehler gelten dieselben Regeln: Eine endgültige Antwort mit expliziten Aktualitätsangaben darf gespeichert werden. Daher kann ein nachgelagerter Cache eine 5xx-Antwort speichern und erneut ausliefern, wenn sie mit derselben langen Gültigkeitsdauer in max-age gesendet wird wie erfolgreiche Antworten. Welche Statuscodes ein bestimmtes CDN speichert, hängt jedoch vom Anbieter ab. Senden Sie no-store bei allen Antworten, die nicht zwischengespeichert werden dürfen, und versehen Sie Fehlerantworten nicht mit Gültigkeitsdauern für erfolgreiche Antworten. Ein CDN kann Fehler auch aufgrund einer eigenen Einstellung zwischenspeichern, die der Header nicht außer Kraft setzt: Amazon CloudFront ignoriert no-store, no-cache und private bei Antworten mit den Statuscodes 500, 502, 503 und 504 und speichert sie für die Dauer der Einstellung Error Caching Minimum TTL. Diese wird pro Statuscode festgelegt und beträgt standardmäßig 10 Sekunden. Diese Fehler werden nicht zwischengespeichert, wenn das Cache-Verhalten die verwaltete Cache-Richtlinie CachingDisabled verwendet.
Der Header des Origin-Servers hat am Edge nicht immer das letzte Wort. Amazon CloudFront verwendet die minimale TTL der Cache-Richtlinie, wenn sie größer als 0 ist, selbst wenn der Origin-Server no-cache, no-store oder private gesendet hat. Eine Edge-Cache-TTL-Regel von Cloudflare setzt s-maxage und Revalidierungsdirektiven außer Kraft. Im Modus FORCE_CACHE_ALL speichert Google Cloud CDN erfolgreiche Antworten unabhängig von den Direktiven des Origin-Servers. Prüfen Sie die TTL- und Überschreibungseinstellungen des CDN, bevor Sie sich darauf verlassen, dass eine Direktive eine Antwort aus einem gemeinsam genutzten Cache fernhält.

Setzen Sie Cache-Control danach, ob eine Antwort öffentlich, privat, unveränderlich oder häufig aktualisiert ist. Widersprüchliche oder zu freizügige Direktiven können private Daten offenlegen oder veraltete Medien im Cache halten.

Wenn Transloadit eine transformierte Datei über Smart CDN ausliefert, setzt der Robot /file/serve den Header Cache-Control des Ergebnisses. Dabei steht die Gültigkeitsdauer für Browser in max-age und eine separate Gültigkeitsdauer für gemeinsam genutzte Caches in s-maxage. Der Parameter cache_duration des Robots setzt beide Direktiven auf denselben Wert. Mit dem Parameter headers werden Ihre eigenen Headerwerte mit den Standardwerten zusammengeführt, wobei Ihre Werte Vorrang haben. Bei signierten URLs für Smart CDN begrenzt zusätzlich die verbleibende Gültigkeitsdauer der Signatur die effektive Cache-Gültigkeitsdauer.

Die Robot-Seite führt die aktuellen Standardgültigkeitsdauern auf.

Entdecken Sie Transloadits Möglichkeiten zur Auslieferung

Was ist der Cache-Control-Header?

So funktioniert der Cache-Control-Header

Wichtige Fakten

Wann der Cache-Control-Header wichtig ist

So hilft Transloadit beim Cache-Control-Header

Quellen

Machen Sie aus Medienwissen eine funktionierende Pipeline