[php] PHP4 in definiertem Verzeichnis unter Apache

[Sebastian Mendel]

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

naja, wollte ich mir eh schon länger mal anschauen ...


>>>> 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.

die Linux-Distributionen setzen fast alle auf mod, oder?
Aber für ISPs scheint es wohl der bequemere Weg zu sein (Fast)CGI zu verwenden


>>>>> 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 

das klang jetzt erst so als wenn Typo3 nicht reibungslos unter allen 
Konfigurationen läuft ...


> 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 ;)

oder doch? ... naja, aber da sind wir ja wieder bei dem Punkt: die Anwendung 
muss unter allen Konfigurationen funktionieren! ;-)

was eine individuelle php.ini überflüssig macht


>>> 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.

naja, ok, bei speziellen Anwendungen macht man sich natürlich nicht die 
Mühe, außer man weiß bereits wie es geht - und das ist ja meißtens das Ding 
mit dem Pfad oder Infos aus Umgebungsvariablen.


-- 
Sebastian