[Support] mod_php ==> PHP / CGI (schlechte) Erfahrungen
Karsten Sievert
karsten at gospelszene.de
Fri Jul 18 18:40:42 CEST 2008
Hallo, Team,
die Umstellung auf PHP/CGI verstehe ich gut, und begrüße sie.
Wie von Euch empfohlen habe ich mit der Umstellung meiner
Seiten auf PHP/CGI begonnen, und einige schmerzliche Erfahrungen
gemacht, die ich hier einfach einmal zum Besten gebe, um anderen
den Umstieg vielleicht zu erleichtern.
In allen Fällen hatte die Installation in gewisser Weise "Recht",
und die Dokumentation war auch zu finden -- aber ihr wisst, wie
schmerzhaft es sein kann, den richtigen Hinweis im Linux- und
Apache-Universum wirklich zu finden.
Ich befolgte zunächst die gute Anleitung (danke für die
Aktualisierung!) unter
http://www.hostsharing.net/dokumentation/installationsanleitungen/php-via-cgi.html
Dann stellte ich gravierende Unterschiede im Verhalten der
PHP-Scripten fest:
=== GET-Parameter ===
GET-Parameter wie .../page.php?parameter=123 wurden nicht mehr
automatisch in globale Variablen übersetzt. Wo bisher stand:
if (!isset($parameter)) $parameter = 0; // default
muss nun z.B. stehen:
if (isset($_GET['parameter']))
$parameter= $_GET['parameter'];
else
$parameter = 0;
=== Fehlermeldungen / Leere PHP-Seiten ===
Wenn beim Parsen von PHP ein Fehler auftritt, liefert Apache evtl.
kein einziges Byte an den Browser, auch keine Fehlermeldung.
Zum Debuggen muss man die PHP-Seite in stdin des phpXXXstubs
senden:
.../cgi/php525stub < page-with-error.php
Andere Fehler, die bisher zu einer Warnung im PHP-Output, aber
ansonsten korrekter Seite geführt haben, führen nun zum Abbruch.
Warnungen im Output, wenn bisher manchmal vertretbar, werden so
zu einem Fatal Error.
=== getallheaders ===
Die Funktion "array getallheaders(void)" steht nicht mehr zur
Ferfügung: In PHP 4.3.0 wurde aus getallheaders() ein Alias für
apache_request_headers(). Tatsächlich wurde die Funktion umbenannt.
Der Grund: diese Funktion funktioniert nur, wenn PHP als Modul für
Apache kompiliert wurde.
Diese Funktion wurde gebraucht, um den Traffic zu reduzieren:
Durch Auswertung von If-Modified-Since konnte kontrolliert ein
"HTTP/1.1 304 Not Modified" gesendet werden. Eine Ersatzlösung
ist die Abfrage von $_SERVER['HTTP_IF_MODIFIED_SINCE']
=== Permissions 1 ===
Hier habe ich beobachtet, dass ein .htaccess mit einer
Zugriffsbeschränkung durch .htpassword im cgi-Verzeichnis nun
die Einstellung in der lokalen .htaccess überschreiben kann.
Logisch: Wenn ich auf .../cgi/php525stub nicht zugreifen kann,
nutzt es nichts, dass eine *.php-Datei public ist. Das kann
(und hat bei mir) zu Problemen führen, man muss evtl. seine
gesamte Zugriffsrechtearchitektur überdenken.
=== Permissions 2 ===
Wenn PHP bisher Dateien angelegt hat, gehörten die httpd
und sind vom Paketuser z.T. nicht zu lesen und nicht zu
löschen. Diese Dateien sind für cgi-php dann auch nicht mehr
erreichbar, und leigen evtl. dauerhaft im Weg.
Ich hoffe, irgend jemandem geholfen zu haben. Ich selber bin
mit der Umstellung noch in der Pilot-Phase: Die wichtigsten
und dicksten Brocken liegen noch vor mir... Für Tipps, wie
man das eine oder andere Problem noch eleganter lösen kann
wäre ich ebenfalls dankbar.
Grüße
-Karsten
More information about the Support
mailing list