Ich wollte doch nur einen Seitenzähler...
Früher, [tm], konnte man in der guten alten Zeit mit Perl als cgi “einfach” einen Seitenzähler bauen. Heute ist Perl nicht mehr so gefragt. In HTML5 hat sich ja auch einiges getan. Also gut, dann eben PHP... Nur so einfach ist das nicht wie früher mit Perl... Alle Beispiele die ich im Netz gefunden habe, funktionieren erstmal nicht. PHP wird vom Webserver auskommentiert. Inline ist PHP verboten. Webserver wie Apache oder Ngnix lassen Code in PHP nur in Dateien mit der Endung *.php zu. Hmm. Dazu kommt, dass die Dokumentation durch die nicht miteinander kompatiblen Versionen von PHP, schlecht ist.
Was also tun?
Bricht man die an mehreren Stellen vesteckte Sicherheitseinstellungen von PHP auf, oder stellt man alle Seiten auf die Endung *.php statt *.html um?
Bei mir habe ich mich für die zweite Variante entschieden.
Damit nicht genug:
Nun sollte der Zähler eine Session nur einmal zählen. Auf dem lokalen Server kein Problem.
Fehlermeldung
Auf dem Root-Server unter nginx kommt es zu folgender Fehlermeldung:
FastCGI sent in stderr: “; PHP message: PHP Warning: sessionsetcookieparams(): Session cookie parameters cannot be changed after headers have already been sent in on line 19; PHP message: PHP Warning: sessionstart(): Session cannot be started after headers have already been sent in while reading upstream, client: 8.8.8.8, server: , request: “GET HTTP/2.0”, upstream: “fastcgi://unix:/run/php/php8.2-fpm.sock:“, host: ““
Und nein, es ist kein Syntax oder irgend etwas mit php/html Problem… Es ist die Datei selber…
Analyse
Nachdem ich einen Tag nach dem vermeindlichem php-Fehler gesucht habe, kam ich auf die Lösung:
hexdump -c index.php|head 0000000 357 273 277 < ! d o c t y p e h t m 0000010 l > \n < h t m l > \n < h e a d > 0000020 \n < m e t a c h a r s e t
Die ersten Bytes erzeugen den BOM-Header, welches den php-Parser vom Ngix zum Straucheln bringt. Mit file kann man sich alle Dateien listen lassen:
file index.php
index.php.karpott: PHP script, UTF-8 Unicode (with BOM) text
BOM ist byte order mark. Viele meiner Webdateien haben diesen Filetyp, > woher auch immer. Weder der Vim noch der Pluma legen solche Dateien an.
Lösung
Mit einem Script habe ich dieses Problem beseitigt.
for i in $(file *.html|grep BOM| sed -e 's/://g'|awk '{print $1}'); do vi -c “:set nobomb” -c “:wq” $i; done
Damit wurden die Bytes am Dateianfang stumpf entfernt.