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 oder If-None-Match und den Antwortstatus 304 .
  • 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 Ressource Expires . Es setzt voraus, dass Server und Clients genaue Uhren haben und Zeitzonen richtig unterstützen. Cache-control: max-age hat Vorrang vor Expires und ist im Allgemeinen zuverlässiger.

  • post-check und pre-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 die Cache-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.



Modified text is an extract of the original Stack Overflow Documentation
Lizenziert unter CC BY-SA 3.0
Nicht angeschlossen an Stack Overflow