Hi,
noch zum fachlichen :-)
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.
Das ist mir schon bewusst - aber auch hier ziert sich vornehme Bescheidenheit vielleicht eher. Es gibt sicher schon genug Dödel, die ihre Ressourcen mit Expires:Irgendwann-im-Jahr-2035 ausliefern - in deren Ränge will ich mich wenn möglich nicht einreihen.
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 ...
Hm, halte ich nur unter Praxis-Gesichtspunkten vielleicht für einen „Idealfall“, weil es genug Leute gibt, die mit ihren Caching-Angaben nicht konsequent sind oder gar Unfug betreiben.
Aber theoretischer Idealfall wäre, dass der Client mich vor Ablauf des Expires-Zeitpunktes gar nicht fragt, wenn er die Ressource noch gecached vorliegen hat. Deshalb auch meine Bedenken, ob sich ein zusätzlich angegebenes Last-Modified nicht vielleicht eher hinderlich auswirkt - weil es beim Client doch „Zweifel“ wecken könnte, ob ich mir mit meiner Expires-Angabe wirklich so sicher war ...
Aber ich merke schon, das werde ich vielleicht am besten irgendwann mal selber in Ruhe ausprobieren, mit einer Reihe von Browsern und Einstellungen und Kontrolle der Logfiles.
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.
Ja, ich denke auch. Wie das mit pre-check/post-check genau war, werde ich wohl noch mal irgendwo nachlesen.
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.
Ja, aber wenn ich die Möglichkeit habe, ihm bei einer heutigen Anfrage zu sagen, das Ding ist noch x Monate gültig (und ich auch nicht vor habe, innerhalb dieses Zeitraums was an der Ressource zu verändern) - dann erscheint mir das sinnvoller, als zu sagen „noch bis übermorgen“.
Zumal, wenn ich Expires von der mtime der Datei abhängig mache, die ich nie zu ändern beabsichtige - dann habe ich ja nach übermorgen ein Problem.
Ich würde intuitiv den Expires-Header bei einem 304-Response weglassen, der Client hat die Information ja schon.
Ja - aber er hat ihr ja vorher schon nicht geglaubt, sonst hätte er nicht erneut nachgefragt.
Mir erscheint es deshalb sinnvoll, Expires durch erneute Angabe noch mal zu bekräftigen, und (siehe vorheriger Absatz) dabei auch gleich noch mal um x Monate in die Zukunft zu datieren. (Vielleicht ist mein Vertrauen in die Lernfähigkeit von Browsern aber auch einfach maßlos überhöht.)
MfG ChrisB
RGB is totally confusing - I mean, at least #C0FFEE should be brown, right?