Langzeit-Caching: Expires-Header mit Last-Modified oder ohne?

[ChrisB]

Hi,

die „externen Ressourcen“ einer Site möchte ich gerne langfristig im Client-Cache lagern lassen - statisches JavaScript, CSS und auch eine handvoll größerer Hintergrundbilder. (Insb., aber nicht nur, letztere sollen bei Aufruf einer Seite so schnell wie möglich zur Verfügung stehen.)

Die werden so selten geändert werden, dass bei Änderung eine neue „Version“ im Ressourcennamen angegeben werden wird, und die Einbindung in den (ebenfalls statisch gecachten, aber häufigerer Änderung unterworfenen) HTML-Dokumenten angepasst wird.

Jetzt frage ich mich, was bzgl. dieses Vorhabens auf HTTP-Ebene am sinnvollsten ist?

Sicherlich wird es einen Expires-Header mit einem weit genug in der Zukunft liegenden Datum geben - vielleicht drei oder sechs Monate (man will den Client-Cache ja auch nicht auf ewig monopolistisch besetzen).

Aber wie sieht es mit einem zusätzlichen Last-Modified-Header aus (Timestamp wäre die mtime der jeweiligen Datei auf dem Server) - „macht das Sinn“, den zusätzlich zum Expires-Header anzugeben?

In den RFCs habe ich erst mal nichts gefunden, was dagegen sprechen würde.

Mein Wunschgedanke wäre, dass sich ein Client, der der Expires-Angabe nicht „vertraut“, obwohl er noch eine gültige Kopie der Ressource im Cache hat, damit erst mal zu einem Conditional GET Request zu bewegen wäre, eine If-Modified-Since-Anfrage stellt, und eine 304-Antwort bekommt, die ihn dann doch wieder dazu bewegt, die bereits im Cache vorliegende Version der Ressource anzuzeigen, was immer noch schneller ginge, als wenn er per GET die komplette Ressource, inkl. Response Body, erneut anfordern würde.

Ist das soweit erst mal durch die Theorie gedeckt? Und hat jemand vielleicht auch Erfahrungen gemacht, ob das in der Praxis so mit den gängigen Clients (Browsern) funktioniert wir vorgestellt?

Insb. beim IE habe ich da Bedenken, weil dessen Caching-Verhalten, abhängig von mehr oder weniger unsinnigen Auswahlmöglichkeiten für den Nutzer, zumindest in der Vergangenheit ja doch öfter abenteuerliche Resultate hervor brachte.
Mir fallen da noch Caching-Header mit Werten wie pre-check/post-check ein, die m.W. IE-spezifisch sind - damit könnte man glaube ich zumindest einen IE, der den Caching-Angaben des Servers nicht vertrauen mag, dazu bringen, erst mal die gecachte Version zur Anzeige zu benutzen, und erst anschließend noch mal beim Server nachzufragen, „ist das Ding noch aktuell?“, so dass es das Laden der eigentlichen Seite nicht verzögernd stört.

Dann noch, zurückkehrend zu obigem, wie/worauf setze ich den Expires-Header - modification plus x Monate, oder lieber access/now plus x Monate?
Mir scheint letzteres sinnvoll, denn wie gesagt, die Ressourcen werden sich nie ändern, und deshalb würde ich sie eher ab Zugriff für x Monate cachen lassen.

Und, zu guter letzt - wenn ich wirklich auf eine If-Modified-Since-Anfrage mit 304 Not Modified antworte, was schicke ich dann (neben dem immer noch gleichen Last-Modified:mtime) für eine Expires-Angabe mit? Auch wieder now + x month, oder lieber gar keine? (Wüsste nicht, warum nicht.)

Danke für's Lesen dieser doch eher lang geratenen Fragestellung. (Beim Kontrolllesen merke ich, dass ich wieder mal ordentlich dem Schachtelsatz gehuldigt habe.)
[Und Disclaimer@Hotti: Nein, ich möchte weder eine Broschüre für kleines Geld von deiner Webseite kaufen, noch wissen, wie du irgendwas vergleichbares in konkretem Perl umgesetzt hast. Mich interessiert vor allem der fachliche Aspekt aus HTTP-Sicht.]

MfG ChrisB