it-swarm.com.de

Wann löschen Browser den Cache und wie kann ich 304 Antworten besser nutzen?

Ich habe eine Website mit einigen Inhalten, die sich häufig ändern.

Ich möchte von einem guten Caching profitieren, wenn sich dies nicht ändert (idealerweise würde ich einen längeren Cache-Control-Header verwenden), aber ich möchte auch sicherstellen, dass die neuesten Informationen verwendet werden (idealerweise würde ich einen kürzeren Cache-Control-Header verwenden). . Diese widersprechen sich offensichtlich.

Das Zwischenspeichern von Daten bietet zwei Vorteile:

  1. Reduzieren Sie alle Aufrufe und verwenden Sie die Version direkt aus dem Cache (wenn die Ressource innerhalb des Zeitrahmens für den Cache-Steuerungsheader verwendet wird).

  2. Verwenden Sie 304 - Nicht geändert als Antwort auf eine Anfrage nach abgelaufenem Inhalt, bei der sich herausstellt, dass es sich immer noch um die neueste Version handelt und die sich immer noch im Browser-Cache befindet (basierend auf ETag oder dem zuletzt geänderten Header in der Anfrage). Dies bedeutet immer noch, dass Sie die Daten anfordern und eine Antwort von 304 erhalten müssen, was einen Umlauf und Latenzprobleme bedeutet (dessen Leistung nicht zu unterschätzen ist!), Also nicht so gut wie bei der ersten Option, aber zumindest Einsparungen bei der vollständiger Download und stellt sicher, dass Sie die neueste Version haben.

Meine Fragen sind also:

Wenn eine HTML-Seite oder ein HTML-Inhalt (CSS, JavaScript, Bilder, Schriftarten usw.) nach Ablauf der Header-Zeit für die Cachesteuerung abgelaufen ist, wie lange bewahren Browser den Inhalt auf, um 304 Antworten zu verwenden?

Kann ich irgendetwas auf Server- oder Anwendungsebene tun, um sicherzustellen, dass Daten für 304 Antworten für eine längere Zeit verfügbar sind? Das heißt Ist es möglich, Daten über einen längeren Zeitraum (z. B. 30 Tage) im Browser zwischenzuspeichern, aber innerhalb einer viel kürzeren Zeit (z. B. nach 3 Stunden) erneut anzufordern, um 304 Antworten mehr zu erhalten? Ich glaube nicht, dass es HTTP-Header zum Speichern im Cache gibt, außer dem Cache-Control-Header, den ich nur für die kürzere Zeit verwenden kann. Vermutet man also, dass dies nur auf die Browser-Implementierung zurückzuführen ist? Ich gehe davon aus, dass Browser regelmäßig ihren Cache mit abgelaufenen Daten leeren, um die Datenträgernutzung gering zu halten, und frage, ob ich Einfluss darauf habe, welche meiner Website-Ressourcen ich gerne aggressiver lösche und welche ich dem Browser empfehlen würde um länger in der hoffnung zu bleiben, dass ein 304 später verwendet werden kann.

P.S. Ich bin mir bewusst, dass Sie dem Dateinamen einen Zeitstempel oder einen anderen eindeutigen Code sowie einen langen Cache-Steuerelement-Header hinzufügen und diesen eindeutigen Teil bei Dateiänderungen aktualisieren können, um das zu erreichen, was ich möchte. Dies bedeutet, dass es für den Browser wie eine neue Ressource aussieht und daher abgerufen wird. Aus verschiedenen Gründen ist dies jedoch nicht immer am einfachsten zu implementieren (und kann nicht auf der Standardseite "index.html" ohne serverseitige Weiterleitungen durchgeführt werden).

2
Barry Pollard

Wenn eine HTML-Seite oder ein HTML-Inhalt (CSS, JavaScript, Bilder, Schriftarten usw.) nach Ablauf der Header-Zeit für die Cachesteuerung abgelaufen ist, wie lange bewahren Browser den Inhalt auf, um 304 Antworten zu verwenden?

Während Browser den Inhalt, der auf der Festplatte gespeichert ist, möglicherweise in einem temporären Verzeichnis oder Cache-Verzeichnis über das Ablaufdatum/die Ablaufzeit hinaus aufbewahren, betrachtet der Browser ihn als veraltet (nicht "frisch") und verweist weiterhin darauf und überprüft ihn erneut, bevor er dies versucht Laden Sie die Datei erneut herunter. Leider behandelt die Spezifikation nicht, wie Browser mit abgelaufenen Dateien umgehen sollen, und die tatsächliche Bereinigung der Dateien auf der Festplatte hängt von den Browser- und Benutzereinstellungen ab (z. B. einer Beschränkung des Speicherplatzes für zwischengespeicherte Dateien) und kann variieren Browser ist geschlossen.

Mark Amery hat eine hervorragende Antwort geschrieben ( Browser-Caching - Anfrage verhindern, die 304 zurückgibt ), die bei der Beantwortung einer anderen Frage die Beziehung zwischen HTTP-304-Antworten und Browser-Caching-Verhalten klar und genau erklärt.

Kann ich irgendetwas auf Server- oder Anwendungsebene tun, um sicherzustellen, dass Daten für 304 Antworten für eine längere Zeit verfügbar sind? Das heißt Ist es möglich, Daten über einen längeren Zeitraum (z. B. 30 Tage) im Browser zwischenzuspeichern, aber innerhalb einer viel kürzeren Zeit (z. B. nach 3 Stunden) erneut anzufordern, um 304 Antworten mehr zu erhalten? Ich glaube nicht, dass es HTTP-Header zum Speichern im Cache gibt, außer dem Cache-Control-Header, den ich nur für die kürzere Zeit verwenden kann. Vermutet man also, dass dies nur auf die Browser-Implementierung zurückzuführen ist?

Ich würde vorschlagen, einfach einen Cache-Control: public, max-age=1080, must-revalidate anzugeben (18 Minuten nach Ihrem Kommentar), und der Browser wird den Inhalt nach diesem Zeitpunkt mit Sicherheit erneut validieren, kann ihn jedoch auch nach eigenem Ermessen während dieser Zeit erneut validieren oder wenn ein Benutzer zum Neuladen auf "Aktualisieren" klickt eine Seite.

Wenn Sie wirklich wollten, können Sie auch versuchen, ETag mit einem MD5-Hash zu vergleichen, anstatt das Datum und die Uhrzeit der letzten Änderung zu überprüfen, um sicherzustellen, dass die Dateien nicht erneut heruntergeladen werden, es sei denn, der Inhalt der Datei hat sich geändert. Wenn Sie viel Verkehr haben, kann es zu einem leichten Leistungseinbruch bei der Berechnung der ETag-Werte für jede Anforderung kommen, und viele Leute lehnen diese Methode entweder wegen des geringen Leistungsabfalls ab und weil viele Leute sie nicht für die Verwendung von MD5 konfigurieren (dies ist der Fall) Um ein serverseitiges Skript zu verwenden, bietet es keinen wirklichen Vorteil gegenüber der letzten Überprüfung von Datum und Uhrzeit und kann sich unregelmäßig verhalten, wenn Dateien von mehreren Servern verteilt werden. Trotzdem kann ein korrekt konfigurierter ETag-Vergleich in Kombination mit langen Ablaufzeiten dazu beitragen, dass weniger Dateien heruntergeladen werden müssen. Stellen Sie vor dem Einrichten von ETags sicher, dass die Webserverkonfiguration so eingerichtet ist, dass persistente Verbindungen verwendet werden, damit Anforderungen auf einer Verbindung sehr schnell verkettet werden können, anstatt dass mehrere Verbindungen erforderlich sind, da alle modernen Browser dies verwenden Dies ist der Fall, wenn Ihr Server dafür eingerichtet ist.

Ich gehe davon aus, dass Browser regelmäßig ihren Cache mit abgelaufenen Daten leeren, um die Datenträgernutzung gering zu halten, und frage, ob ich Einfluss darauf habe, welche meiner Website-Ressourcen ich gerne aggressiver lösche und welche ich dem Browser empfehlen würde um länger in der hoffnung zu bleiben, dass ein 304 später verwendet werden kann.

Sie können in der Tat eine andere Cache-Zeit für verschiedene Ressourcen auf Ihrer Website angeben. Zum Beispiel, wenn Sie einen Unterordner (zum Beispiel lib ) haben, in dem Sie Bibliotheken/Code von Drittanbietern wie jQuery, requireJS oder FontAwesome für speichern Zum Beispiel könnten Sie dann die Version in den Ordnernamen aufnehmen (zB http://www.example.com/lib/fontawesome-4.3.0/) und dann die maximale oder zumindest eine sehr lange Cache-Zeit für alles innerhalb dieser lib Ordner, da Sie keine Änderungen direkt an Code/Dateien von Drittanbietern vornehmen und zukünftige Versionen unter neuen Ordnern mit dem enthaltenen Versionsnamen eingeführt werden. Statische Ressourcen (. Js, . Css, . Jpg, . Png usw.), die für Ihre Website-Vorlage verwendet werden und sich von Zeit zu Zeit ändern können, kann eine kürzere Cache-Zeit festgelegt werden.

# Cache third party files for 1 year (31536000 seconds)
<Directory "/var/www/public_html/lib">
  <IfModule mod_expires.c>
    Header set Cache-control max-age=31536000
  </IfModule>
</Directory>

# Cache template files for 1 day (86400 seconds)
<Directory "/var/www/public_html/tpl">
  <IfModule mod_expires.c>
    Header set Cache-control max-age=86400
  </IfModule>
</Directory>

P.S. Ich bin mir bewusst, dass Sie dem Dateinamen einen Zeitstempel oder einen anderen eindeutigen Code sowie einen langen Cache-Steuerelement-Header hinzufügen und diesen eindeutigen Teil bei Dateiänderungen aktualisieren können, um das zu erreichen, was ich möchte. Dies bedeutet, dass es für den Browser wie eine neue Ressource aussieht und daher abgerufen wird. Aus verschiedenen Gründen ist dies jedoch nicht immer am einfachsten zu implementieren (und kann nicht auf der Standardseite "index.html" ohne serverseitige Weiterleitungen durchgeführt werden).

Sie haben vollkommen recht, diese sind nicht einfach in einer effektiven und effizienten Weise zu implementieren und erfordern viel mehr Aufwand/Code als die Verwendung der HTTP-Protokoll-Header, wie sie beabsichtigt waren. Das einzige mir bekannte Szenario, in dem diese Art von Lösung manchmal bevorzugt wird, ist für plattformübergreifende Software wie Content-Management-Systeme, bei denen alle verschiedenen Webserver-Umgebungen konsistent unterstützt werden sollen. Wenn ihre Software beispielsweise in PHP geschrieben wurde, können sie eine Lösung implementieren, die vollständig in PHP erreicht werden kann, anstatt .htaccess-Regeln zu verwenden.


Hinzugefügt am 04.06.2015:

Zum Browserverhalten abgelaufener ("veralteter") zwischengespeicherter Dateien:

"Eine gespeicherte Antwort gilt als" frisch ", wie in Abschnitt 4.2 definiert, wenn die Antwort ohne" Validierung "wiederverwendet werden kann (prüfen Sie beim Origin-Server, ob die zwischengespeicherte Antwort für diese Anforderung gültig bleibt). Eine neue Antwort kann daher verwendet werden Reduzieren Sie bei jeder erneuten Verwendung die Latenz und den Netzwerkaufwand. Wenn eine zwischengespeicherte Antwort nicht aktuell ist, kann sie möglicherweise immer noch wiederverwendet werden, wenn sie durch Validierung aktualisiert werden kann (Abschnitt 4.3) oder wenn Origin nicht verfügbar ist (Abschnitt 4.2.4). "

Quelle: RFC 7234: HTTP-Caching , letzter Absatz der Einführung.

Zum Verhalten der Must-Revalidate-Direktive:

"Die Antwortanweisung" must-revalidate "gibt an, dass ein Cache, sobald er veraltet ist, die Antwort NICHT verwenden DARF, um nachfolgende Anforderungen ohne erfolgreiche Validierung auf dem Origin-Server zu erfüllen."

Quelle: RFC 7234: HTTP-Caching , 5.2.2.1. Muss erneut validiert werden.

2
richhallstoke

Wenn Sie mit statischen Seiten arbeiten (z. B. Dateien mit den HTML-Erweiterungen), kann die Header-Konfiguration nur auf Serverkonfigurationsdateien angewendet werden. Je nach Server sind die Konfigurationsoptionen möglicherweise eingeschränkt.

Verwenden Sie eine serverseitige Skriptsprache wie PHP, um mehr Flexibilität zu erzielen, ohne den Server zu beschädigen.

Für die Cachesteuerung möchten Sie außerdem die Option "Muss erneut validiert werden" verwenden, damit der Browser den Server nach Ablauf des Caches erneut auf die benötigte Ressource überprüft.

Wenn der Browser beim 304 die Ressource erneut anfordert, gibt er einen Wert an eine Serverumgebungsvariable aus, wenn seit oder wenn keine Übereinstimmung vorliegt, je nachdem, ob Sie die eTags oder den zuletzt geänderten Header verwenden. Der Server (oder das vom Server ausgeführte Skript) gibt dann ein 304 aus, wenn er glaubt, dass die Variable die erforderlichen Daten enthält. Suchen Sie bei Google nach if-modified-since und if-none-match, und erfahren Sie mehr darüber, wie diese funktionieren.

0
Mike