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

[Der Martin]

Hallo,

die „externen Ressourcen“ einer Site möchte ich gerne langfristig im Client-Cache lagern lassen [...]
Jetzt frage ich mich, was bzgl. dieses Vorhabens auf HTTP-Ebene am sinnvollsten ist?

es überrascht mich, dass gerade du diese Frage stellst, wo du doch eigentlich zu den "alten Hasen" gehörst, die ihr Handwerk verstehen. Denke ich zumindest ...

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).

Keine Sorge. In der Regel haben die Browser eine Obergrenze für den Speicherplatz, den sie für den Cache belegen. Normalerweise fliegt dann irgendwann der älteste oder der am wenigsten verwendete Inhalt wieder raus. Damit löst sich das Problem der Fairness im Cache von selbst.

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?

Finde ich auf jeden Fall sinnvoll.

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.

Das ist eigentlich der Idealfall, den ich bei meinen Browsern auch immer einstelle: Egal, was der Server beim vergangenen Abruf einer Ressource mal als Gültigkeitsdauer angegeben hat - einfach mal fragen gehen. Könnt ja sein ...

Ist das soweit erst mal durch die Theorie gedeckt?

Und durch Praxis. IE, Opera und Firefox benutze ich seit Jahren mit dieser clientseitigen Strategie.

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.

Ja, der ist "von Haus aus" so eingestellt, dass er eine einmal gecachte Ressource bis zum jüngsten Tag immer wieder aus dem Cache holt, ohne überhaupt nachzufragen, ob die überhaupt noch aktuell ist. Das würde deinem aktuellen Vorhaben also volle Kanne entgegenkommen.
Wenn er dagegen vom Nutzer weniger aggressiv eingestellt wird, so dass er doch erst mal mit If-Modified-Since anfragt, passt's ja auch.

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.

Ich glaube, das macht für die Praxis keinen Unterschied. Der Browser sieht: Das Ding ist noch ein paar Tage oder Monate gültig.

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.)

Gute Frage, habe ich so noch nicht darüber nachgedacht. Ich würde intuitiv den Expires-Header bei einem 304-Response weglassen, der Client hat die Information ja schon.

Danke für's Lesen dieser doch eher lang geratenen Fragestellung. (Beim Kontrolllesen merke ich, dass ich wieder mal ordentlich dem Schachtelsatz gehuldigt habe.)

Willkommen im Club. ;-)

[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.]

*fg*

Ciao,
 Martin