Vollständige Seite neu laden auf Post/Redirect/Ignorieren Cache-Steuerelement

Question

Ich habe eine Seite, die eine Menge Bilder, CSS und Javascript geladen. Ich habe einen Far-Futures-Expires-Header hinzugefügt und Cache-Control für diese externen Abhängigkeiten öffentlich gesetzt, sodass sie zwischengespeichert werden sollten. Aber jedes Mal, wenn ich eine Post/Redirect/Get chrome versuche, diese wieder zu laden. Dieses Verhalten ähnelt dem erneuten Laden der Seite. Ich habe ETags hinzugefügt und handle den If-None-Match-Header, der ein wenig hilft, aber es erzeugt immer noch zu viele nutzlose Anfragen.

Wie kann ich Chrom und Safari sagen, um die Dateien aus dem Cache zu bekommen?

chrome NOK 
safari NOK 
firefox OK 
ie  OK 

Siehe auch Full page reload on Post/Redirect/Get ignoring cache control auf dem Google-Support-Forum.

Klarstellung:

Ich will nicht der Browser image1.png zweimal beantragen. Es sollte zwischengespeichert werden.

200 GET page1.html 
200 GET image1.png (Cache-Control: public, Expires and ETag) 
302 POST action.asp (form submitted from page1.html, redirects) 
200 GET page2.html 
304 GET image1.png (If-None-Match) 

Beispiel:

ich ein einfaches Beispiel erstellt haben, das Problem zu veranschaulichen.

http://crydust.be/lab/prg/

Headers:

Die Header ich mit dem Bild senden sind:

HTTP/1.1 200 OK 
Date: Fri, 18 Jun 2010 11:30:22 GMT 
Server: Apache 
Cache-Control: public, max-age=86400 
Expires: Sat, 19 Jun 2010 11:30:24 GMT 
Etag: "123" 
Content-Length: 866 
Content-Type: image/png 

Welche sollte es für 24 Stunden zwischengespeichert werden. Es gibt kein Vary: * oder ähnliches.

Aktualisierung: Dieses Verhalten ist jetzt auch in Safari Mobile auf iOS 4 vorhanden. Eine schreckliche Regression in der Seitenladegeschwindigkeit.

Update: Es gibt einen Bugreport über dieses Problem im Webkit Bugzilla. Bug 38690 - Submitting a POST that leads to a server redirect causes all cached items to redownload

Update: Das Problem auf iOS weiterhin besteht 4.0.1

Update: Das Problem weiterhin besteht auf iOS 4,1

Update: Das Problem auf iOS weiterhin besteht 4.2

Aktualisierung: Das Problem weiterhin besteht auf iOS 4.2.1 und in Chrome ab Version 6 bis 9.

Update: Es gibt einen Bugreport über dieses Thema im Projekt Chromium.(Sie können es Sterne zu zeigen, die Sie interessieren) Issue 68621: Post/Redirect/Get ignoring cache instructions

Update: Das Problem weiterhin besteht auf Chrome ab Version 6 bis 10. Es ist jetzt eine 9 Monate alte Fehler.

Update: Das Problem ist seit 2011-03-21 19:33:07 PST behoben. Dies spiegelt sich im Verhalten von chrome 12 (canary) wider.

Answer 1

Wenn Sie F5/in Chrome, Safari oder IE8 aktualisieren, werden alle GET-Ressourcen erneut angefordert, auch wenn sie zwischengespeichert wurden.

Wenn Sie die Anfrage/Antwort mit den Dev-Tools oder Fiddler beobachten, sehen Sie, dass der Server mit einem HTTP 304-Status und ohne Inhalt antwortet. Dies teilt dem Browser mit, dass er ihn nicht erneut herunterladen muss und dass er den Cache weiterhin verwenden kann.

In den Ressourcen-Tab-Dateien der Chrome-Entwicklungstools, die so aktualisiert wurden, wird eine Latenzzeit, aber eine Downloadzeit von 0 ms angezeigt.

Wenn Sie die Seite erneut laden und zurückgeben, werden Sie feststellen, dass diese zwischengespeicherten Dateien nicht erneut abgerufen werden und der Server nicht überprüft wird.

Dieses Verhalten von F5/aktualisieren für GET statische Ressource ist richtig - es ist FX und IE6, die es falsch machen. Es hilft auch mit dem verwirrenden STRG + F5 Befehl, den die meisten Benutzer nicht kennen.

Sie können nicht POST oder Seiten-Cache, die eine temporäre HTTP-Umleitung zurück:

Daten POST Änderungen und sollte immer aufgefordert, bevor sie wieder gesendet werden, und ihre Ergebnisse werden nicht zwischengespeichert.

Redirects werden auf einer niedrigen Ebene im HTTP-Stuff behandelt - unterhalb des Caching. Wirklich es teilt dem Browser mit, die Ressource von woanders zu bekommen und während es cachen kann, dass es die Weiterleitung nicht zwischengespeichert hat und erneut überprüfen muss.

Sie sollten in der Lage sein, eine permanente 301-Weiterleitung zwischenzuspeichern, aber eine 302 oder 303 temporäre Weiterleitungen sollten nicht zwischengespeichert werden according to the HTTP spec.

Answer 2

F5 lädt alle Ressourcen der Seite in einigen Browsern neu, so dass sie die Cache-Header ignorieren und erneut nach jeder Ressource fragen.

Wenn Sie POST-Seiten "cachen" möchten, müssen Sie diese Seiten in statische Ressourcen konvertieren, d. H. Eine HTML-Datei aus der .php generieren und dann die .html als statische Ressource bereitstellen.

Dies ist nur gültig, wenn der Inhalt der Seite nicht

Answer 3

Das Update ändert: cache-control: no-store

(Sie können auch Statuscode 307 statt 302, verwenden, die das Verfahren erhalten werden.)

Die Lösung wurde auf this open WebKit bug viele Tage der Frustration in einem Kommentar-after gefunden:

CachedRawResource behält jetzt die Redirect-Kette und hat eine triviale Logik zur Überprüfung der Korrektheit, aber sie ist bei weitem nicht vollständig (prüft nur cacheControlContainsNoStore()).Und natürlich haben andere Ressourcentypen nichts.