Dies bedeutet ja nicht, das die Dateien deswegen in einem cgi-Ordner liegen müssen
Doch, genau das ist der Unterschied. Vor 20 Jahren, als ich mit dem Kram angefangen habe, da gab es nur CGI und alle Skripte mussten in cgi-bin liegen. Irgendwann kam PHP und das funktionierte mit einmal überall. Man musste seine Seite nicht mehr über mehrere Ordner verteilen, nur weil man ein paar aktive Inhalte haben wollte. Das das eine Konfigrationssache des Webservers bzw. Hosters ist, darüber brauchen wir nicht reden. Das ist mir als Webentwickler oder Homepagebetreiber auch egal. Neben dieser Bevorzugung hatte PHP keine Vorteile. In allen Benchmarks lag PHP deutlich hinter Perl und später Python zurück. Gegen CPAN kam PEAR und PECL nicht an. Und als ausgewiesene Web-Sprache hatte PHP bis vor kurzem nicht mal einen Opcode-Cache an Board, das musste erst von außen ran gebastelt werden.
"Doch, genau das ist der Unterschied. Vor 20 Jahren, als ich mit dem Kram angefangen habe, da gab es nur CGI und alle Skripte mussten in cgi-bin liegen."
Du brichst hier einige Techniken sowie Konfiguration durcheinander (bzw. so verstehe ich deinen Text) CGI ist erst einmal nur eine Art, wie der Webserver mit einem externen Programm kommuniziert, um eine Anfrage beantworten zu können. Aus Sicherheitsgründen haben die meisten Webserver per Default einen cgi-bin Ordner vorgesehen. ABER: Dies war nicht Teil dessen, was CGI ist, sondern nur eine Konvention, die man auch durchgehend ändern konnte.
Zudem geht es in diesem Fall um eine Lösung, bei der ein Interpreter als CGI aufgerufen wird, um einen Script auszuführen. Das ist nicht identisch mit dem Ausführen eines Scriptes, der selbst den Interpreter definiert.
Beispiel: Du hast einen Script mit shebang (#!...), der definiert das der Script als Interpreter Python zu nutzen hat. Du packst diesen Script in den cgi-bin Ordner, und markierst ihn als ausführbar. Daneben legt du eine Binärdatei, die ebenfalls als CGI nutzbar ist.
Beide werden nun vom Webserver entsprechend ausgeführt, einer mit dem verlangten Interpreter, der andere direkt. Jeweils als CGI (also über Pipes und co. als Kommunikation)
PHP aber war als CGI meist anders konfiguriert. Hier wurde dem Webserver mitgeteilt, welcher Interpreter für die Dateiendung .php zuständig ist, sodass dieser mit der PHP Datei als Parameter aufgerufen wurde. Derlei ging auch mit so gut wie jedem anderen Interpreter, war aber seltener genutzt. Technisch möglich war es aber immer. In diesem Fall hatte der hochladende Webmaster gar keine Wahl, welchen Interpreter er wählt. Der Script konnte überall liegen, und es konnte eben auch nur ein Script sein, und nicht z.B. eine Binärdatei. Dies hat den Vorteil, das der Webserver-Betreiber bestimmen kann, was der Interpreter tun kann (durch Änderung dessen Config oder Quellcode). Da der User den Interpreter nicht frei wählen kann, ist dies eine sicherere Lösung, und entsprechend gelten üblicherweise keine Einschränkungen auf den cgi-bin Ordner. Wobei natürlich auch dort Sicherheitsvorkehrungen nötig sind. Insofern war es immer eine eher seltsame Konvention, die alleine nie ausreichend war.
Der cgi-bin Ordner war also eine Konvention, aber kein muss. Auch vorher schon konnte man das sehr wohl anders lösen, und diese wurde auch getan. Andere Lösungen wie fast-cgi (aber nicht nur), bei denen Permanent ein Interpreter lief, gibt es bis heute im Einsatz. Diese verbinden die Vorteile von CGI (eigene Userprozesse getrennt vom Webserver), mit denen einer schnellen Ausführung.
Der Vorteil von PHP war, wenn man es als mod_php nutze, das man keinen Interpreter bei jedem Aufruf starten musste, was beim normalen CGI nötig war, und gut und gerne eine halbe Sekunde Ausführungszeit gekostet haben kann. Aber es gab eben auch ein CGI-PHP, und dennoch waren dei Scripte nicth an cgi-bin gebunden.
Was soll dieses endlose Geschreibsel? Bitte lese doch mal, worauf die geantwortet hast. Mit
"Derlei ging auch mit so gut wie jedem anderen Interpreter, war aber seltener genutzt."
bestätigst Du meine Aussage. Der Rest ist komplett am Thema vorbei, außer Du willst mir unterstellen, dass ich nicht weiß was CGI ist.
btw: Kennst du einen prägnanten, kurzen und für jedermann verständlichen Begriff der den klassischen Weg ein CGI Skript zu starten beschreibt? Wenn ja, bitte her damit.
Doch, genau das ist der Unterschied. Vor 20 Jahren, als ich mit dem Kram angefangen habe, da gab es nur CGI und alle Skripte mussten in cgi-bin liegen. Irgendwann kam PHP und das funktionierte mit einmal überall. Man musste seine Seite nicht mehr über mehrere Ordner verteilen, nur weil man ein paar aktive Inhalte haben wollte. Das das eine Konfigrationssache des Webservers bzw. Hosters ist, darüber brauchen wir nicht reden. Das ist mir als Webentwickler oder Homepagebetreiber auch egal. Neben dieser Bevorzugung hatte PHP keine Vorteile. In allen Benchmarks lag PHP deutlich hinter Perl und später Python zurück. Gegen CPAN kam PEAR und PECL nicht an. Und als ausgewiesene Web-Sprache hatte PHP bis vor kurzem nicht mal einen Opcode-Cache an Board, das musste erst von außen ran gebastelt werden.
"Doch, genau das ist der Unterschied. Vor 20 Jahren, als ich mit dem Kram angefangen habe, da gab es nur CGI und alle Skripte mussten in cgi-bin liegen."
Du brichst hier einige Techniken sowie Konfiguration durcheinander (bzw. so verstehe ich deinen Text)
CGI ist erst einmal nur eine Art, wie der Webserver mit einem externen Programm kommuniziert, um eine Anfrage beantworten zu können.
Aus Sicherheitsgründen haben die meisten Webserver per Default einen cgi-bin Ordner vorgesehen.
ABER: Dies war nicht Teil dessen, was CGI ist, sondern nur eine Konvention, die man auch durchgehend ändern konnte.
Zudem geht es in diesem Fall um eine Lösung, bei der ein Interpreter als CGI aufgerufen wird, um einen Script auszuführen.
Das ist nicht identisch mit dem Ausführen eines Scriptes, der selbst den Interpreter definiert.
Beispiel:
Du hast einen Script mit shebang (#!...), der definiert das der Script als Interpreter Python zu nutzen hat. Du packst diesen Script in den cgi-bin Ordner, und markierst ihn als ausführbar.
Daneben legt du eine Binärdatei, die ebenfalls als CGI nutzbar ist.
Beide werden nun vom Webserver entsprechend ausgeführt, einer mit dem verlangten Interpreter, der andere direkt. Jeweils als CGI (also über Pipes und co. als Kommunikation)
PHP aber war als CGI meist anders konfiguriert. Hier wurde dem Webserver mitgeteilt, welcher Interpreter für die Dateiendung .php zuständig ist, sodass dieser mit der PHP Datei als Parameter aufgerufen wurde. Derlei ging auch mit so gut wie jedem anderen Interpreter, war aber seltener genutzt. Technisch möglich war es aber immer.
In diesem Fall hatte der hochladende Webmaster gar keine Wahl, welchen Interpreter er wählt. Der Script konnte überall liegen, und es konnte eben auch nur ein Script sein, und nicht z.B. eine Binärdatei.
Dies hat den Vorteil, das der Webserver-Betreiber bestimmen kann, was der Interpreter tun kann (durch Änderung dessen Config oder Quellcode).
Da der User den Interpreter nicht frei wählen kann, ist dies eine sicherere Lösung, und entsprechend gelten üblicherweise keine Einschränkungen auf den cgi-bin Ordner.
Wobei natürlich auch dort Sicherheitsvorkehrungen nötig sind. Insofern war es immer eine eher seltsame Konvention, die alleine nie ausreichend war.
Der cgi-bin Ordner war also eine Konvention, aber kein muss. Auch vorher schon konnte man das sehr wohl anders lösen, und diese wurde auch getan.
Andere Lösungen wie fast-cgi (aber nicht nur), bei denen Permanent ein Interpreter lief, gibt es bis heute im Einsatz. Diese verbinden die Vorteile von CGI (eigene Userprozesse getrennt vom Webserver), mit denen einer schnellen Ausführung.
Der Vorteil von PHP war, wenn man es als mod_php nutze, das man keinen Interpreter bei jedem Aufruf starten musste, was beim normalen CGI nötig war, und gut und gerne eine halbe Sekunde Ausführungszeit gekostet haben kann.
Aber es gab eben auch ein CGI-PHP, und dennoch waren dei Scripte nicth an cgi-bin gebunden.
Was soll dieses endlose Geschreibsel? Bitte lese doch mal, worauf die geantwortet hast. Mit
"Derlei ging auch mit so gut wie jedem anderen Interpreter, war aber seltener genutzt."
bestätigst Du meine Aussage. Der Rest ist komplett am Thema vorbei, außer Du willst mir unterstellen, dass ich nicht weiß was CGI ist.
btw: Kennst du einen prägnanten, kurzen und für jedermann verständlichen Begriff der den klassischen Weg ein CGI Skript zu starten beschreibt? Wenn ja, bitte her damit.