Kampf gegen den Cache

[dedlfix]

Tach!

Ich finde aber Martins Ansatz gar nicht verkehrt, Ressourcen mit Querystring erstmal gar nicht zu cachen.

Warum dies? Ein Querystring sagt (im Prinzip) nicht aus, dass eine solche Ressource ständigen Änderungen ausgesetzt ist.

Es ist halt ziemlich egal, ob die Seite, die das Impressum, die Admins, ... zeigt, jedesmal neu generiert wird oder nicht. Bei ebay, Foren, Fratzenbuch, Zufalls-Generatoren, ... aber eben nicht.

Und wo ist da der Unterschied zu einer URL ohne Querystring? Es gibt auch querystringlose Seiten, die sich ständig ändern. Wie der Browser damit umgehen soll, musst über die Cache-Angaben geregelt werden.

Mir erscheint cachen erst auf ausdruecklichen Wunsch hier sinnvoller.

Das verwechselst du vielleicht mit lokalem Speichern der Seite? Oder meinst du das aus Sicht des Servers? Dann hindert dich ja niemand, selbigen entsprechend zu konfigurieren. Alle Angaben zum Cachen und zur Gültigkeitsdauer eines Dokuments (Expires) sind optional und haben sich erst im Laufe der Zeit entwickelt. Client haben also zumindest früher schon immer geachcht wie sie wollten. Das kannst du nun sinnvoll finden oder nicht, aber ändern wirst du nichts daran.

-----

Jetzt hab ich doch nochmal die HTTP-Specs überflogen. In HTTP 1.0 habe ich zu GET in Bezug auf Cache nicht viel gefunden. Nur bei POST steht, dass ein solcher Request nicht gecacht werden darf.

HTTP 1.1 widmet der Cache-Problematik ein eigenes Haupt-Kapitel. Da steht auch was zu Nebenwirkungen von GET und HEAD.

"Unless the origin server explicitly prohibits the caching of their responses, the application of GET and HEAD methods to any resources SHOULD NOT have side effects that would lead to erroneous behavior if these responses are taken from a cache."

GET muss also ohne weitere Cache-Angaben immer daselbe liefern. Und dann kommt da die Ausnahme von der Regel:

"We note one exception to this rule: since some applications have traditionally used GETs and HEADs with query URLs (those containing a "?" in the rel_path part) to perform operations with significant side effects, caches MUST NOT treat responses to such URLs as fresh unless the server provides an explicit expiration time."

Also alles mit "?" muss, weil es einige Browser mal so gemacht haben es jetzt zum Standard erhoben wurde, ohne weitere Cache-Angaben als unfrisch angesehen werden.

dedlfix.