Wir sollten hier mal ein paar Begriffe klären, die du konsequent falsch benutzt. Ein Parser ist ein Programm, das einen Eingabestrom in eine abstrakte Repräsentation übersetzt. Der Eingabestrom ist oft eine Zeichenkette, die Ausgabe typischerweise ein abstrakter Syntaxbaum. Ein Parser erwartet immer, dass die Eingabe einem bestimmten Format folgt. Nur wenn die Eingabe wirklich dieses Format hat, kann der Parser daraus eine abstrake Repräsentation erzeugen. Falls nicht, dann bricht ein Parser ab und meldet einen Syntax-Fehler. Es macht keinen Sinn einem JSON-Parser einen CSV-String zu geben oder umgekehrt. Genausowenig macht es Sinn einem Parser für `multipart/form-data` einen Eingabestrom im `application/x-www-form-urlencoded` Format zu geben. All diese Fälle sollten Syntax-Fehler produzieren. CGI ist eine Spezifikation, die eine Laufzeit-Umgebung für Webserver standardisiert. Darin wird zum Beispiel festgelegt, dass die Querystring-Komponente der angefragten URL in einer Umgebungsvariable namens `QUERYSTRING` gespeichert werden soll. Da wird aber nicht festgelegt, welches Format die Querystring-Komponente hat, und auch nicht ob sie geparst werden soll. Weiterhin steht in CGI, dass der HTTP-Body über eine nicht-weiter spezifizierte Systemfunktion gelesen werden können muss. CGI schreibt ausdrücklich nicht vor, ob und in welchem Format der Body geparst werden soll. CGI.pm und mod_cgi sind Implementierungen dieses Standards. Ein Skript, das in diesem Kontext ausgeführt wird, hat Zugriff auf die Umgebungsvariablen, die CGI festlegt und sie haben irgendeine Möglichkeit den HTTP-Body zu lesen. Das kann, muss aber nicht der STDIN-Kanal sein. Eine Implementierung kann darüber hinaus auch eigene Design-Entscheidungen treffen. Wenn eine HTTP-Anfrage eintrifft, kann eine Implementierung auch den Body und den Content-Type-Header auswerten und dann intern einen Parser für den Content-Type wählen und versuchen den Body in eine abstrakte Repräsentation zu übersetzen. Oder die Implementierung kann einfach ins Blaue versuchen den Body mit verschiedenen Parsern zu dekodieren. Das ist aber alles Zusatzverhalten, das nicht von CGI so spezifiziert wurde. Es ist eine Frage der konkreten Implementierung, nicht von CGI, wie du vorher behauptet hast. Neben CGI gibt es außerdem noch andere Standards, die ebenfalls Laufzeitumgebungen für Webserver spezifizieren, wie FastCGI. Und es gibt Laufzeitumgebungen, die keiner Spezifikation folgen, wie mod_php. CGI ist heute mehrfach überholt und kommt nur noch selten zum Einsatz, insbesondere im PHP-Kosmos spielt CGI keine große Rolle mehr.

Wir sollten hier mal ein paar Begriffe klären, die du konsequent falsch benutzt. Ein Parser ist ein Programm, das einen Eingabestrom in eine abstrakte Repräsentation übersetzt. Der Eingabestrom ist oft eine Zeichenkette, die Ausgabe typischerweise ein abstrakter Syntaxbaum. Ein Parser erwartet immer, dass die Eingabe einem bestimmten Format folgt. Nur wenn die Eingabe wirklich dieses Format hat, kann der Parser daraus eine abstrake Repräsentation erzeugen. Falls nicht, dann bricht ein Parser ab und meldet einen Syntax-Fehler. Es macht keinen Sinn einem JSON-Parser einen CSV-String zu geben oder umgekehrt. Genausowenig macht es Sinn einem Parser für `multipart/form-data` einen Eingabestrom im `application/x-www-form-urlencoded` Format zu geben. All diese Fälle sollten Syntax-Fehler produzieren. CGI ist eine Spezifikation, die eine Laufzeit-Umgebung für Webserver standardisiert. Darin wird zum Beispiel festgelegt, dass die Querystring-Kompentente der angefragten URL in einer Umgebungsvariable namens `QUERYSTRING` gespeichert werden soll. Da wird aber nicht festgelegt, welches Format die Querystring-Komponente hat, und auch nicht ob sie geparst werden soll. Weiterhin steht in CGI, dass der HTTP-Body über eine nicht-weiter spezifizierte Systemfunktion gelesen werden können muss. CGI schreibt ausdrücklich nicht vor, ob und in welchem Format der Body geparst werden soll. CGI.pm und mod_cgi sind Implementierungen dieses Standards. Ein Skript, dass in diesem Kontext ausgeführt wird, hat Zugriff auf die Umgebungsvariablen, die CGI festlegt und sie haben irgendeine Möglichkeit den HTTP-Body zu lesen. Das kann, muss aber nicht der STDIN-Kanal sein. Eine Implementierung kann darüber hinaus auch eigene Design-Entscheidungen treffen. Wenn eine HTTP-Anfrage eintrifft, kann eine Implementierung auch den Body und den Content-Type-Header auswerten und dann intern einen Parser für den Content-Type wählen und versuchen den Body in eine abstrakte Repräsentation zu übersetzen. Oder die Implementierung kann einfach ins Blaue versuchen den Body mit verschiedenen Parsern zu dekodieren. Das ist aber alles Zusatzverhalten, dass nicht von CGI so spezifiziert wurde. Es ist eine Frage der konkreten Implementierung, nicht von CGI, wie du vorher behauptet hast. Neben CGI gibt es außerdem noch andere Standards, die ebenfalls Laufzeitumgebungen für Webserver spezifizieren, wie FastCGI. Und es gibt Laufzeitumgebungen, die keiner Spezifikation folgen, wie mod_php. CGI ist heute mehrfach überholt und kommt nur noch selten zum Einsatz, insbesondere im PHP-Kosmos spielt CGI keine große Rolle mehr.

Wir sollten hier mal ein paar Begriffe klären, die du konsequent falsch benutzt. Ein Parser ist ein Programm, dass einen Eingabestrom in eine abstrakte Repräsentation übersetzt. Der Eingabestrom ist oft eine Zeichenkette, die Ausgabe typischerweise ein abstrakter Syntaxbaum. Ein Parser erwartet immer, dass die Eingabe einem bestimmten Format folgt. Nur wenn die Einabe wirklich dieses Format hat, kann der Parser daraus eine abstrake Repräsentation erzeugen. Falls nicht, dann bricht ein Parser ab und meldet einen Syntax-Fehler. Es macht keinen Sinn einen JSON-Parser einen CSV-String zu geben oder umgekehrt. Genausowenig macht es Sinn einen Parser für `multipart/form-data` einen Eingabestrom im `application/x-www-form-urlencoded` Format zu geben. All diese Fälle sollten Syntax-Fehler produzieren. CGI ist eine Spezifikation, die eine Laufzeit-Umgebung für Webserver standadisiert. Darin wird zum Beispiel festgelegt, dass die Querystring-Kompentente der angefragten URL in einer Umgebungsvariable namens `QUERYSTRING` gespeichert werden soll. Da wird aber nicht festgelegt, welches Format die Querystring-Komponente hat, und auch nicht ob sie geparst werden soll. Weiterhin steht in CGI, dass der HTTP-Body über eine nicht-weiter spezifizierte Systemfunktion gelesen werden können muss. CGI schreibt ausdrücklich nicht vor, ob und in welchem Format der Body geparst werden soll. CGI.pm und mod_cgi sind Implementierungen dieses Standards. Ein Skript, dass in diesem Kontext ausgeführt wird, hat Zugriff auf die Umgebungsvariablen, die CGI festlegt und sie haben irgendeine Möglichkeit den HTTP-Body zu lesen. Das kann, muss aber nicht der STDIN-Kanal sein. Eine Implementierung kann darüber hinaus auch eigene Design-Entscheidungen treffen. Wenn eine HTTP-Anfrage eintrifft, kann eine Implementierung auch den Body und den Content-Type-Header auswerten und dann intern einen Parser für den Content-Type wählen und versuchen den Body in eine abstrakte Repräsentation zu übersetzen. Oder die Implementierung kann einfach ins Blaue versuchen den Body mit verschiedenen Parsern zu dekodieren. Das ist aber alles Zusatzverhalten, dass nicht von CGI so spezifiziert wurde. Es ist eine Frage der konkreten Implementierung, nicht von CGI, wie du vorher behauptet hast. Neben CGI gibt es außerdem noch andere Standards, die ebenfalls Laufzeitumgebungen für Webserver spezifizieren, wie FastCGI. Und es gibt Laufzeitumgebungen, die keiner Spezifikation folgen, wie mod_php. CGI ist heute mehrfach überholt und kommt nur noch selten zum Einsatz, insbesondere im PHP-Kosmos spielt CGI keine große Rolle mehr.