phpbar.de logo

Mailinglisten-Archive

[php] PHP4 in definiertem Verzeichnis unter Apache

[php] PHP4 in definiertem Verzeichnis unter Apache

Ulf Seltmann seltmann at digitalzone.de
Mon Jan 21 19:01:21 CET 2008


Sebastian Mendel schrieb:
> ahso, läuft bei FastCGI ähnlich wie bei mod der PHP Prozess ständig, oder so 
> was ähnliches?
genau.

>>> oben bezeichnest du es als 'krank' durch Konfiguration Probleme zu lösen,
>> Ich bezeichne es (aus Administratorensicht) als krank, _solch_ eine 
>> Konfiguration zu bewerkstelligen. Wenn du anderer Meinung bist, wie wäre 
>> es mit ein paar Argumenten?
> 
> Wieso brauch ich Argumente es nicht als krank zu bezeichnen, versteh ich 
> nicht? ich sehe keinen Nachteil darin PHP einmal als mod und einmal als CGI 
> in einem Apache zu verwenden und wollte halt nur von dir wissen warum du es 
> anders siehst.
Ich habe versucht es zu erklären, aber Erfahrungswerte lassen sich nur 
schlecht als Argumente einsetzen.

>>> oh, mod ist also schneller als CGI, das spricht aber eher gegen CGI, oder?
>> das einzige, was _für_ CGI spricht, ist Sicherheit zusammen mit suexec 
>> und das verzeichnisabhängige Umschalten der PHP-Version mittels 
>> .htaccess (und individuelle php.ini's).
> 
> na ok, die zwei Sachen kannte ich bisher auch, es hatte sich nur so gelesen 
> als wenn es da wesentlich mehr gebe, und nichts für mod sprechen würde, 
> dachte halt nur ich hätte da was verpasst bsiher.
Ich halte mittlerweile nicht mehr viel von mod_php. es lässt sich zwar 
schön leicht einrichten, aber von Sicherheit ist nicht viel übrig. CGI 
ist zu langsam, bleibt nur noch FastCGI, IMHO die beste Lösung.

>>>> Environment-Variablen unterscheiden sich auch von CGI zu mod_php, was in 
>>>> der Programmierung erhebliche Schwierigkeiten machen kann.
>>>> Mal von den PHP ausführenden Benutzern ganz abgesehen.
>>> Programmiert man nicht eh so das es in beiden Umgebungen läuft!?
>>> bzw. das Framework auf das man setzt.
>> Hast du schon ein Framework mit "Interpreterweiche"? Ich nicht.
> 
> Mit Interpreterweiche? Nein. Wozu sollte man sowas brauchen?
> Nehmen wir z. B. mal phpMyAdmin, meines Erachtens läuft das doch auf allen 
> Konfigurationen, oder?
Und was hältst du von Typo3? Leider muss ich mich damit herumschlagen 
mit dem Ergebnis, dass an vielen Stellen auf php_sapi_name() geprüft 
wird, was in vielen Umgebungen verschiedene Werte zurückliefert 
(SuSE,Debian,XAMPP) und entsprechend Pfade zusammenbaut. Sowas verstehe 
ich unter einer "Interpreterweiche" (in Anlehnung an den gebräuchlichen 
Begriff "Browserweiche", der Web-Designer immer einen Schauer über den 
Rücken laufen lässt ;)

>> Kleines Beispiel: in PHP4 ist die Variable $_SERVER['SCRIPT_FILENAME'] 
>> bei CGI der Interpreter, bei mod_php ist es das PHP-Script. Bei PHP5 ist 
>> es für CGI und mod_php wieder gleich, nämlich das PHP-Script, aber es 
>> gibt eine neue Variable $_SERVER['ORIG_SCRIPT_FILENAME'], die den 
>> Interpreter enthält.
> 
> yepp, und? dieses Problem umgehst du durch individuelle php.ini's???
> Das ist genau ein Argument dafür das Anwendungen mit allen Umgebungen 
> umgehen könne müssen weil du dieses Problem eben nicht durch individuelle 
> php.ini's umgehen kannst, oder?
Richtig. Damit wären wir wieder bei der "Interpreterweiche".
So etwas tun wir nicht. Unsere Testumgebung entspricht (weitgehend ;) 
der Live-Umgebung. Wenn sich die Live-Umgebung ändert, migrieren wir die 
Applikation (insofern nicht abwärtskompatibel) auf die neue Umgebung.

ciao

Ulf

php::bar PHP Wiki   -   Listenarchive