Cache-Control
Das allgemeine Header-Feld Cache-Control
wird benutzt um Direktiven für Caching-Mechanismen, sowohl für Requests als auch für Responses, zu spezifizieren. Caching-Direktiven sind unidirektional, das bedeutet dass eine Direktive in einem Request nicht impliziert, dass die gleiche Direktive auch in einem Response zurückkommen muss.
Header type | General header (en-US) |
---|---|
Forbidden header name | nein |
CORS-safelisted response-header (en-US) | ja |
Syntax
Die Direktiven beachten Groß- und Kleinschreibung und haben optionale Argumente, die sowohl Token-Syntax als auch Zeichenketten mit Anführungszeichen verwenden. Mehrere Direktiven werden kommasepariert.
Cache Request Direktiven
Standard Cache-Control
Direktiven, die vom Client in einem HTTP Request verwendet werden können.
Cache-Control: max-age=<seconds> Cache-Control: max-stale[=<seconds>] Cache-Control: min-fresh=<seconds> Cache-Control: no-cache Cache-Control: no-store Cache-Control: no-transform Cache-Control: only-if-cached
Cache Response Direktiven
Standard Cache-Control
Direktiven, die vom Server in einer HTTP Response verwendet werden können.
Cache-Control: must-revalidate Cache-Control: no-cache Cache-Control: no-store Cache-Control: no-transform Cache-Control: public Cache-Control: private Cache-Control: proxy-revalidate Cache-Control: max-age=<seconds> Cache-Control: s-maxage=<seconds>
Erweiterungs Cache-Control
Direktiven
Erweiterungs Cache-Control
Direktiven sind nicht Teil des Kern HTTP Caching Standard-Dokuments. Prüfen Sie die Unterstützung in der Kompatibilitätstabelle.
Cache-Control: immutable Cache-Control: stale-while-revalidate=<seconds> Cache-Control: stale-if-error=<seconds>
Direktiven
Cachebarkeit
public
- Kennzeichen dass die Response von jedem Cache gecached werden dürfen.
private
- Kennzeichen dass die Response für einen einzigen Benutzer gedacht ist, und nicht von einem geteilten Cache gespeichert werden dürfen. Ein privater Cache darf die Response speichern.
no-cache
- Zwingt Caches den Request dem Ursprungs-Server zuzustellen, um die Gültigkeit zu validieren, bevor eine gecachte Kopie freigegeben wird.
only-if-cached
- Gibt an, dass keine neue Daten abgerufen werden sollen. Der Client möchte nur eine gecachte Response erhalten und sollte nicht den Ursprungs-Server kontaktieren, um zu prüfen, ob eine neuere Kopie existiert.
Cache-Verfall
max-age=<seconds>
- Spezifiziert die maximale Zeitdauer, die eine Ressource als aktuell betrachtet wird. Im Gegensatz zu
Expires
, ist diese Direktive relativ zum Zeitpunkt des Requests. s-maxage=<seconds>
- Überschreibt
max-age
oder denExpires
Header, bezieht sich allerdings nur auf geteilte Caches (z.B. Proxyserver) und wird von einem privaten Cachen ignoriert. max-stale[=<seconds>]
- Gibt an, dass der Client bereit ist eine Response zu akzeptieren, die ihre Ablaufzeit überschritten hat. Optional können Sie einen Wert in Sekunden angeben, der die Zeit angibt, die eine Response höchstens abgelaufen sein darf.
min-fresh=<seconds>
- Gibt an, dass der Client eine Response erwartet, die mindestens noch für die angegebene Zeit aktuell ist.
stale-while-revalidate=<seconds>
- Gibt an, dass der Client bereit ist eine abgelaufene Response zu akzeptieren, während im Hintergrund asynchron auf eine Aktualisierung geprüft wird. Der zweite Wert gibt an für wie lange der Client bereit ist die abgelaufene Response zu akzeptieren.
stale-if-error=<seconds>
- ...
Revalidierung und Neuladen
must-revalidate
- Der Cache muss den Status der abgelaufenen Ressource überprüfen bevor sie verwendet wird. Abgelaufene Ressourcen sollten nicht verwendet werden.
proxy-revalidate
- Gleich wie
must-revalidate
, aber bezieht sich nur auf geteilte Caches (z.B. Proxyserver) und wird von einem privaten Cache ignoriert. immutable
- Gibt an, dass der Response-Body sich nicht im Laufe der Zeit ändern wird. Falls die Ressource noch nicht abgelaufen ist, ist sie auf dem Server unverändert und daher sollte der Client, selbst wenn der Benutzer die Seite explizit aktualisiert, nicht eine bedingte Revalidierung schicken (z.B.
If-None-Match
oderIf-Modified-Since
) , um auf Aktualisierungen zu prüfen Die Ressource . Clients, denen diese Erweiterung unbekannt ist, müssen sie nach der HTTP-Spezifikation ignorieren. In Firefox,immutable
wird nur beihttps://
Transaktionen beachtet. Für mehr Informationen, siehe auch diesen Blogpost.
Weitere
no-store
- Der Cache sollte nichts über den Client-Request oder die Server-Response speichern.
no-transform
- Es sollte keinerlei Transformation oder Konvertierung der Ressoruce durchgeführt werden. Die Content-Encoding, Content-Range, Content-Type Headers dürfen nicht durch einen Proxyserver verändert werden. Ein nicht-transparenter Proxy könnte beispielsweise zwischen Bildformaten konvertieren, um Speicherplatz im Cache zu sparen oder den Datenverkehr bei einer langsamen Verbindung zu reduzieren. Die
no-transform
Direktive verbietet dies.
Beispiele
Caching verhindern
Um Caching abzuschalten können Sie den folgenden Response Header schicken. Beachten Sie ggf. zusätzlich die Expires
und Pragma
Header.
Cache-Control: no-cache, no-store, must-revalidate
Statische Assets cachen
Für die Dateien einer Anwendung, die sich nicht ändern werden, können Sie normalerweise aggressives Caching nutzen, indem Sie den untenstehenden Response-Header senden. Dies schließt statische Dateien ein, die von der Anwendung bereitgestellt werden, wie z.B. Bilder, CSS- und JavaScript-Dateien. Beachten Sie außerdem den Expires
Header.
Cache-Control: public, max-age=31536000
Spezifikationen
Specification | Title |
---|---|
RFC 7234 | Hypertext Transfer Protocol (HTTP/1.1): Caching |
RFC 5861 | HTTP Cache-Control Extensions for Stale Content |
RFC 8246 | HTTP Immutable Responses |
Browser Kompatibilität
BCD tables only load in the browser
The compatibility table in this page is generated from structured data. If you'd like to contribute to the data, please check out https://github.com/mdn/browser-compat-data and send us a pull request.