Frage Ideale HTTP-Cache-Steuerköpfe für verschiedene Arten von Ressourcen


Ich möchte eine minimale Menge von Headern finden, die mit "allen" Caches und Browsern funktionieren (auch bei Verwendung von HTTPS!)

Auf meiner Website habe ich drei Arten von Ressourcen:

(1) Immer zwischenspeicherbar (öffentlich / für alle Benutzer gleich)

Beispiel: 0A470E87CC58EE133616F402B5DDFE1C.cache.html (automatisch generiert von GWT) 

  • Diese Dateien erhalten automatisch einen neuen Namen, wenn sie den Inhalt ändern (basierend auf dem MD5).

  • Sie sollten so viel wie möglich zwischengespeichert werden, selbst wenn HTTPS verwendet wird (also nehme ich an, ich sollte einstellen Cache-Control: public, besonders für Firefox?)

  • Sie sollten nicht verlangen, dass der Client einen Round-Trip zum Server durchführt, um zu überprüfen, ob sich der Inhalt geändert hat.

(2) Gelegentlich wechseln (öffentlich / gleich für alle Benutzer)

Beispiele: index.html, mymodule.nocache.js

  • Diese Dateien ändern ihren Inhalt, ohne die URL zu ändern, wenn eine neue Version der Site bereitgestellt wird.

  • Sie können zwischengespeichert werden, benötigen aber wahrscheinlich eine Rundreise, die jedes Mal erneut validiert werden muss.

(3) Individuell für jede Anfrage (privat / benutzerspezifisch)

Beispiel: JSON-Antworten

  • Diese Ressourcen sollten unter keinen Umständen unverschlüsselt auf die Festplatte zwischengespeichert werden. (Außer vielleicht habe ich ein paar spezifische Anfragen, die zwischengespeichert werden könnten.)

Ich habe eine allgemeine Vorstellung davon, welche Header ich für jeden Typ verwenden würde, aber es gibt immer etwas, was mir fehlen könnte.


76
2018-06-04 01:23


Ursprung


Antworten:


Ich würde wahrscheinlich diese Einstellungen verwenden:

  1. Cache-Control: max-age=31556926 - Repräsentationen können von jedem Cache zwischengespeichert werden. Die zwischengespeicherte Darstellung gilt für 1 Jahr als frisch:

    Um eine Antwort als "Nie abläuft" zu markieren, sendet ein Ursprungsserver ein    Läuft ab Datum ungefähr ein Jahr ab dem Zeitpunkt der Antwort   geschickt. HTTP / 1.1 Server SOLLTEN NICHT senden Läuft ab Termine mehr als eins   Jahr in der Zukunft.

  2. Cache-Control: no-cache - Repräsentationen dürfen von jedem Cache zwischengespeichert werden. Caches müssen jedoch die Anfrage zur Validierung an den Ursprungsserver senden, bevor eine zwischengespeicherte Kopie freigegeben wird.
  3. Cache-Control: no-store - Caches dürfen die Repräsentation unter keinen Umständen zwischenspeichern.

Sehen Mark Nottinghams Caching-Lernprogramm Für weitere Informationen.


83
2018-06-08 21:49



Die Fälle eins und zwei sind eigentlich das gleiche Szenario. Sie sollten einstellen Cache-Control: public und dann generieren Sie eine URL mit der Build-Nummer / Version der Site, so dass Sie unveränderliche Ressourcen haben, die möglicherweise für immer dauern könnten. Sie möchten auch die Expires Header ein Jahr oder mehr in der Zukunft, so dass der Client keinen Frische-Check ausstellen muss.

Für Fall 3 könnten Sie alle folgenden für maximale Flexibilität:

"Cache-Control", "no-cache, must-revalidate"
"Expires", 0
"Pragma", "no-cache"

-2
2018-06-08 01:36