500er, die niemand sieht: wenn staticfilecache den Fehler verdeckt

Tipps und Tricks TYPO3 Webserver

Ein kaputtes PHP-Setup muss nicht auffallen: Liefert staticfilecache die vorgenerierten Seiten direkt über den Webserver aus, sehen Besucher weiterhin eine gesunde Seite. Der 500er trifft nur, was tatsächlich durch PHP läuft – und ob das passiert, hängt ausgerechnet am Accept-Encoding-Header.
teilen
drucken

Nach einem Deploy sah die Startseite im Browser tadellos aus. Ein curl-Aufruf auf dieselbe Adresse lieferte dagegen einen 500er mit leerem Rumpf. Beides war richtig.

Terminal 

curl -s -o /dev/null -w '%{http_code}\n' -A 'Mozilla/5.0' example.org
500

curl -s -o /dev/null -w '%{http_code}\n' -A 'Mozilla/5.0' \
     -H 'Accept-Encoding: gzip' example.org
200

staticfilecache legt fertig gerenderte Seiten als Dateien ab, die der Webserver direkt ausliefert – ohne PHP überhaupt zu starten. Für die gzip-Variante gibt es eine eigene Datei. Wer Accept-Encoding: gzip sendet, bekommt sie und damit eine gesunde Seite. Wer den Header weglässt, landet im PHP-Pfad und sieht den eigentlichen Zustand.

Praktisch heißt das: Browser senden den Header immer, Besucher merken also nichts. Kaputt sind die Bereiche, die nie aus dem statischen Cache kommen – das Backend unter /typo3/, Formularabsendungen, alles mit aktiver Session. Und ein Monitoring, das brav wie ein Browser anfragt, meldet weiterhin grün.

Beide Wege prüfen, nicht nur einen 

for h in '' 'Accept-Encoding: gzip'; do
    curl -s -o /dev/null -w "%{http_code} " ${h:+-H "$h"} example.org
done; echo

Wer ein Monitoring einrichtet, sollte deshalb mindestens eine Prüf-URL ohne Accept-Encoding abfragen – oder gleich eine Seite, die nie statisch ausgeliefert wird.


Erstellt am:

Zurück