HTTP
HTTP-Antworten zwischenspeichern
Suche…
Bemerkungen
Die Antworten werden für jede URL und jede HTTP-Methode separat zwischengespeichert.
HTTP-Caching ist in RFC 7234 definiert.
Glossar
- fresh - Status einer zwischengespeicherten Antwort, die noch nicht abgelaufen ist. In der Regel kann eine neue Antwort Anforderungen erfüllen , ohne dass der Server kontaktiert werden muss, von dem die Antwort stammt.
- stale - Zustand einer zwischengespeicherten Antwort, deren Ablaufdatum überschritten ist. Normalerweise können veraltete Antworten nicht verwendet werden, um eine Anforderung zu erfüllen, ohne beim Server zu prüfen, ob sie noch gültig ist.
- Eine befriedigte zwischengespeicherte Antwort erfüllt eine Anforderung, wenn alle Bedingungen in der Anforderung mit der zwischengespeicherten Antwort übereinstimmen, z. B. dieselbe HTTP-Methode und URL, die Antwort neu ist oder die Anforderung veraltete Antworten zulässt, Anforderungsheader stimmen mit den im Antwortkopf "
Vary
Header überein . - Revalidierung - Prüfen , ob eine zwischengespeicherte Antwort frisch ist. Dies erfolgt normalerweise mit einer bedingten Anforderung, die
If-Modified-Since
oderIf-None-Match
und den Antwortstatus304
. - privater Cache - Cache für einen einzelnen Benutzer, z. B. in einem Webbrowser. Private Caches können personalisierte Antworten speichern.
- Öffentlicher Cache - Cache, der von vielen Benutzern gemeinsam genutzt wird, z. B. in einem Proxyserver. Ein solcher Cache kann dieselbe Antwort an mehrere Benutzer senden.
Cache-Antwort für alle für 1 Jahr
Cache-Control: public, max-age=31536000
public
bedeutet, dass die Antwort für alle Benutzer gleich ist (sie enthält keine personalisierten Informationen). max-age
ist in wenigen Sekunden. 31536000 = 60 * 60 * 24 * 365.
Dies wird für statische Assets empfohlen, die sich niemals ändern sollen.
Eine personalisierte Antwort für 1 Minute zwischenspeichern
Cache-Control: private, max-age=60
private
gibt an, dass die Antwort nur für Benutzer zwischengespeichert werden kann, die die Ressource angefordert haben, und nicht erneut verwendet werden kann, wenn andere Benutzer dieselbe Ressource anfordern. Dies ist angemessen für Antworten, die von Cookies abhängen.
Stoppen Sie die Verwendung von zwischengespeicherten Ressourcen, ohne vorher den Server zu überprüfen
Cache-Control: no-cache
Der Client verhält sich so, als wäre die Antwort nicht zwischengespeichert worden. Dies ist angemessen für Ressourcen, die jederzeit unvorhersehbar geändert werden können und die Benutzer immer in der neuesten Version sehen müssen.
Antworten mit no-cache
werden langsamer (hohe Latenzzeit), da der Server bei jeder Verwendung erneut kontaktiert werden muss.
Doch um Bandbreite zu sparen, können immer noch die Kunden solche Antworten speichern. Antworten no-cache
werden nicht verwendet, um Anforderungen zu erfüllen, ohne den Server jedes Mal zu kontaktieren, um zu prüfen, ob die zwischengespeicherte Antwort erneut verwendet werden kann.
Beantworten Sie die Antworten nicht, um überhaupt gespeichert zu werden
Cache-control: no-store
Weist Clients an, die Antwort auf keine Weise zu zwischenspeichern und so schnell wie möglich zu vergessen.
Diese Direktive wurde ursprünglich für sensible Daten entwickelt (heutzutage sollte stattdessen HTTPS verwendet werden), sie kann jedoch verwendet werden, um die Verschmutzung von Caches zu vermeiden, deren Antworten nicht wiederverwendet werden können.
Dies ist nur in bestimmten Fällen sinnvoll, in denen die Antwortdaten immer unterschiedlich sind, z. B. ein API-Endpunkt, der eine große Zufallszahl zurückgibt. Andernfalls können no-cache
und Revalidierung verwendet werden, um ein Verhalten einer "nicht cachbaren" Antwort zu haben, während dennoch etwas Bandbreite eingespart werden kann.
Veraltete, redundante und nicht standardmäßige Header
Expires
- gibt das Datum an, an dem die RessourceExpires
. Es setzt voraus, dass Server und Clients genaue Uhren haben und Zeitzonen richtig unterstützen.Cache-control: max-age
hat Vorrang vorExpires
und ist im Allgemeinen zuverlässiger.post-check
undpre-check
- Richtlinien sind nicht-Standard - Internet - Explorer - Erweiterungen , die Verwendung von veralteten Antworten ermöglichen. Die Standardalternative ist "stale-while-revalidate
.Pragma: no-cache
- 1999 veraltet. Stattdessen sollte dieCache-control
verwendet werden.
Zwischengespeicherte Ressourcen ändern
Die einfachste Methode, den Cache zu umgehen, besteht darin, die URL zu ändern. Dies wird als bewährte Methode verwendet, wenn die URL eine Version oder eine Prüfsumme der Ressource enthält, z
http://example.com/image.png?version=1
http://example.com/image.png?version=2
Diese beiden URLs werden separat zwischengespeichert. Selbst wenn …?version=1
für immer zwischengespeichert wurde, konnte eine neue Kopie sofort als …?version=2
abgerufen werden.
Bitte verwenden Sie keine zufälligen URLs, um Caches zu umgehen. Verwenden Sie Cache-control: no-cache
oder Cache-control: no-store
. Wenn Antworten mit zufälligen URLs ohne die Direktive no-store
gesendet werden, werden sie unnötig in Caches gespeichert und nützlichere Antworten aus dem Cache herausgeschoben, wodurch die Leistung des gesamten Caches beeinträchtigt wird.