Clientside Cache Control

Auf techblog.tilllate.com gab es vor kurzer Zeit einen recht interessanten Ansatz zur Cache-Kontrolle durch den User. Dieses ist eine deutsche Erklärung dazu, die noch einen kleinen Schritt weiter geht.

Jeder Webworker hat wohl schon mal Caching in seine Applikationen eingebaut. Spätestens, wenn der Server fast am Krepieren ist und der Kunde Sturm klingelt, weil seine Website nicht mehr zu erreichen ist, ist es soweit. Die mit Abstand häufigste Caching-Form ist dabei wohl das serverseitige Cachen, bei dem die Website-Administratoren dann selbst entscheiden, wie oft sich ein Cache erneuert. Leider sorgt das bei den Besuchern gern mal für Unmut, wenn z.B. der User in dem seiteninternen Messaging-System nicht mehr sieht, ob er schon eine neue Nachricht bekommen hat.

Was tun in einem solchen Fall? Man möchte die User ja nicht vergraulen. Andererseits darf der Server auch nicht in die Knie gehen.

Die Lösung: den User selbst dafür sorgen lassen, dass sich der Server-Cache zur richtigen Zeit erneuert.

Auf die Tastenkürzel kommt es an

Die meisten wissen, dass man z.B. im Firefox per Strg+Shift+R dafür sorgen kann, dass der Browser-eigene Cache übergangen wird. Weniger bekannt ist, dass in diesem Fall auch zusätzliche Request Header an den Server geschickt werden. Anschauen kann man dieses sehr gut, wenn man die verschiedenen Reload-Varianten mal auf requestheaders.com ausprobiert.

Beim Check sieht man, dass entweder der Header cache-control (HTTP/1.1) oder pragma (HTTP/1.0) mitgeschickt wird. Beide entweder mit dem Wert no-cache oder max-age=0.

Wie in dem Original-Bericht habe ich mal überprüft, bei welchen Browsern verwertbare Request Header mitgeschickt werden, wobei ich ein paar Tastenkombinationen mehr unter die Lupe genommen habe. Lustigerweise kommen bei mir zum Originalartikel abweichende Ergebnisse heraus:

Browser	URL-Enter	F5	Strg+F5	Strg+R	Strg+Shift+R
Firefox 3.0.4	O	O	X	O	X
IE 7	O	O	X	O	-
IE 6	O	O	O	O	-
Safari 3.1.2 (Windows)	O	X	-	X	-
Opera 9.51	O	X	-	X	-
Chrome	X	X	X	X	-

X: cache-control oder pragma wurden mitgeschickt
O: keine zusätzlicher Header wurde mitgeschickt
-: Die Tastenkombination ist in dem Browser nicht möglich

Fazit:

Bei jedem Browser kommt unter bestimmten Bedingungen ein gültiger Wert heraus. Man könnte es also dem User überlassen, ob ein serverseitiger Cache invalide wird. Da die Befehle ja auch nur gesendet werden, wenn ein User explizit einen Reload anordnet, während er die Seite eh schon auf dem Schirm hat, kann das auch als forcierter und gewollter Reload betrachtet werden. Der User will also schauen, ob es eine neue Variante gibt.

Sehr viel mehr Traffic dürfte für den Server im Normalfall nicht herauskommen, weil die User normalerweise nur von Seite zu Seite springen und daher ziemlich selten die benötigten Header absenden.

Ich werde das wohl in Kürze einbauen, weil es auch für mich als Entwickler eine Erleichterung ist, den Cache während der Entwicklung einfach per Tastendruck zu umgehen.

Der Originalartikel: http://techblog.tilllate.com/2008/11/14/clientside-cache-control/
RFC2616: HTTP/1.1: Header Field Definitions
http://www.requestheaders.com