Kontrolle des HTTP-Cachings mit Perl

Ein Anwender gibt eine Webadresse in seinem Browser ein. Der Browser holt die Seite vom Webserver. Der Anwender betrachtet das Ergebnis. Dann tun tausend Anwender gleichzeitig dasselbe, und das Netzwerk wird quälend langsam, der Server bricht zusammen, und alle Anfragen erhalten veraltete Seiten. Das ist nicht gerade angenehm. Wenn der Programmierer auf Server-Seite nur daran gedacht hätte, HTTP Caching und Expiry zu nutzen…

Mehr als nur Server und Browser

Wenn man an seiner Testumgebung sitzt und den Server-Code einer neuen Anwendung auf Herz und Nieren prüft, scheint alles völlig problemlos. Hier besteht die Umgebung nur aus einem Test-Client-Computer mit einem Browser und einem Test-Webserver. Wenn es doch im wirklichen Leben auch so einfach wäre…

In der Realität ist nur Ihr Server der eigentliche HTTP-„Ursprungs-Server“. Zwischen ihm und dem Web-Browser des Anwenders kann eine beliebige Zahl von Proxy-HTTP-Servern liegen, jeder mit seinen eigenen Caching-Richtlinien. HTTP bietet ein komplexes Content Negotiation Model, mit der man eine URL vom eigenen Server abrufen lassen kann. In Wirklichkeit kommt die Seite aber von einem dazwischen geschalteten Proxy-Server, der sie von einer früheren Anfrage noch gespeichert hat. Von diesem Proxy erfährt man vielleicht nie etwas. Dies alles dient zur Entlastung der Internet-Bandbreite. Wer sich für die trockenen Details interessiert, findet sie in der RFC 2616 („Hypertext Transfer Protocol: HTTP/1.1“).

Für statische Informationen wie Bilder und reine HTML-Seiten ist diese Kette von Proxy-Caches recht praktisch. Wenn tausend Anwender dieselbe URL eingeben, werden viele Anfragen von einem Proxy bedient. Dies entlastet sowohl den Server als auch die Netzwerk-Bandbreite in der Nähe des Servers.

Doch im Fall von dynamischen Informationen, wie sie z. B. von jeder Web-basierten Anwendung bereitgestellt werden, stellen Proxy-Caches einen Grund zur Besorgnis dar. Woher soll man wissen, ob nicht irgendwo da draußen in einem Cache eine Stunden, Tage oder gar Wochen alte Seite auf eine Browser-Anfrage wartet?

Das HTTP-Protokoll enthält einige Schutzmaßnahmen gegen dieses Risiko. Alle HTTP Request-Response-Paare sollten erforderlichenfalls „semantisch transparent“ sein. Das bedeutet nichts anderes, als dass das Vorhandensein von Proxys zwischen dem Ursprungsserver und dem Client keine Auswirkungen auf den Inhalt der übertragenen Informationen haben darf.

Diese Semantik-Garantie basiert darauf, dass beide Seiten sich an die Spielregeln von HTTP halten. Wenn eine Webseite von Ihrem Programm dynamisch erstellt wird, könnten Sie für einige dieser Header-Informationen verantwortlich sein. Sie sollten also wissen, welche Header einzufügen sind.