Das Cache-Verhalten eines Proxys kann - neben der eigenen Konfiguration - sowohl vom Client als auch vom Webserver beeinflusst werden. Für einen gut funktionierenden Cache müssen die Betreiber der Webserver und die Webdesigner auch Cache-freundliche Seiten erstellen und die Clients müssen entsprechend konfiguriert sein, um einen Cache-Proxy auch optimal zu nutzen.
Webserver können beim Ausliefern eines Objekts zusätzliche Informationen in einem Header 3.2senden. [2.1.5]
Für den Proxyserver sind u.a. folgende Header-Daten von besonderem Interesse:
Beispiel:
Cache-Control: max-age=86400, must-revalidate Expires: Tue, 30 Jul 2002 19:43:45 GMT Last-Modified: Thu, 30 May 2002 01:31:01 GMT
Webautoren oder -designer haben bei der Seitenerstellung und beim Webdesign auch erheblichen Einfluss auf die Cache-Freundlichkeit ihrer Seiten.
Insbesondere bei Scripten werden meist keine Header-Daten generiert, so dass ein Proxy oder Browser keine weiteren Informationen über die Aktualität der erhaltenen Daten bekommt und diese nicht im Cache ablegt.
Klickt der Anwender dann beim Surfen mit dem Button [Back] oder [Zurück] erneut über das Script, werden auch die gleichen Daten erneut angefordert.
Es wird sicher einige Scripte geben, die wirklich dynamisch sind, d.h., dass sie bei jedem Aufruf auch ein anderes Ergebnis liefern. Erfahrungsgemäß werden jedoch in den meisten Scripten die gleichen Daten erscheinen. Es wäre also - je nach Daten - eine Haltbarkeitszeit von fünf Minuten bis zu einer Stunde durchaus vertretbar. Das würde bewirken, dass ein Klicken über dasselbe Script dieselben Daten aus dem Cache liefern könnte und nicht der Webserver bemüht werden müsste, die Daten erneut zu generieren und zu senden.
Beispiel: Ein "Cache-Control: max-age=600" im Header der gesendeten Daten würde diese 10 Minuten lang im Proxy oder Browser speichern.
Der Client ist ebenfalls in der Lage, durch die Formulierung seiner
Anfrage das Cache-Verhalten des Proxys zu beeinflussen.
Drückt der Anwender beispielsweise auf [STRG] + [Reload]/[Aktualisieren]
in seinem Browser, sendet dieser in seiner Anfrage an den Proxy ein
Pragma no-cache mit, was den Proxy veranlasst, nicht
den Cache zu durchsuchen, sondern das Objekt direkt vom Webserver
zu holen.
Viele Browser verfügen darüber hinaus über einen eigenen Cache, den sie je nach Konfiguration vor einer Anfrage an den Proxyserver nutzen.
Die Möglichkeiten, das Cache-Verhalten zu manipulieren, sind vielfältig. Für jede dieser Möglichkeiten gibt es durchaus sinnvolle Anwendungen. Die Fülle der Möglichkeiten führt jedoch auch manchmal zu unerwünschten Nebeneffekten.
Der Betreiber eines Cache-Proxys verfolgt i.d.R. das Ziel, seine Zugriffe zu beschleunigen und Bandbreite im Netz einzusparen. Ein einmal geholtes Objekt muß bei Folgeanfragen nicht mehr vom entfernten Webserver geholt werden, sondern wird aus dem schnelleren Cache geliefert.
Auch seriösen Webserver-Betreibern kommt dies normalerweise entgegen, da auch hier Bandbreite gespart wird, wenn nicht jede Anfrage vom Webserver selbst beantwortet werden muss.
Nun gibt es im Internet jedoch auch viele werbefinanzierte Angebote. Ein Webserver-Betreiber, der sich über Werbung finanziert, muss seinen Werbeplatz auch irgendwie vermarkten. Ein Webserver, der häufig angefragt wird, ist für Werbepartner interessanter als einer, der vielleicht gerade mal 10 Klicks am Tag hat.
Also sind solche Webserver-Betreiber - obwohl es durchaus auch andere Lösungsansätze gibt - nicht selten daran interessiert, möglichst viele Anfragen auf ihrem Webserver zu protokollieren. Sie werden also jede sich bietende Möglichkeit nutzen, einen Proxyserver zu umgehen.
Auch der verstärkte Einsatz von dynamischen Seiten und Datenbanken schränkt die Cache-Möglichkeiten eines Proxys immer weiter ein. Meiner Erfahrung nach sind - je nach Nutzungsverhalten - nur noch etwa 30-50% aller Objekte im Internet cachebar. Die Tendenz ist hierbei klar abnehmend.