Regina Schaukrug: Das Cachen des Outputs ist manchmal heikel, aber machbar

Beitrag lesen

Wenn die Sprache nicht in der URL auftaucht kann es zu verschiedenen Problemen mit anderen Tools kommen.

Das ist absolut richtig. Allerdings würde ich selbst den Einsatz von mod_cache wegen einiger Seiteneffekte längst nicht in jedem Fall empfehlen.

Nämlich wenn z.B. das Ergebnis eines erfolgreichen Logins in der SESSION oder in einem COOKIE herumgeschleppt wird kann es dazu kommen, dass mode_cache an nicht autorisierte Benutzer Inhalte ausliefert.

Auch bei der Antwort auf Anfragen, die mittels POST-Request erfolgen muss man dann als Entwickler/Betreiber sehr vorsichtig sein und ggf. ansonsten gesendete Caching-Header abschalten.

Was aber mit mode_cache immer geht ist die Auslieferung statischen Contents - soweit es keine Beschränkungen hinsichtlich der Abrufbarkeit geben soll. Manche Seiten verwenden deshalb für eben solchen statischen, öffentlichen Content eine Subdomain (webseite auf http[s]://www.foo.example; Grafiken, CSS, JS auf http[s]://static.foo.example. Das muss keine Maschine sein, denn schließlich lässt sich mod_chache aber nicht nur in der server-config sondern auch für virtuelle Hosts (static kann ein solcher sein) und "per dir" konfigurieren, also auch ein- oder oder ausschalten. So wäre es denkbar, zu cachende Inhalte explizit unter http[s]://www.foo.example/static/ unterzubringen und das Caching nur für dieses Verzeichnis zu aktivieren.

Wird kein statischer Content ausgeliefert kann es zu dem effektiver sein, die Ausgaben von CGI-Skripten oder eben PHP selbst zu cachen, u.a. weil man in einem eigenen Cache sogar gezippte Versionen des Outputs vorhalten kann und den nur für die zwei Abrufe pro Jahr (es gibt kaum http-Clients, die nur ungepackte Daten verstehen) vor dem Versand auspackt. Selbst für packbaren statischen Content , insbesondere alle Dateien, die Text oder ungepackte Daten beinhalten, z.B. bmp) kann man auch mit PHP was stricken...