Email: Request-Header Content-Type und XHR

Beitrag lesen

Ergänzung: CGI/1.1 legt also nur fest, wie ein Webserver einen HTTP Request aufzuarbeiten hat. Und so macht ein Webserver nichts weiter als dies:

  1. den Stream aus dem Socket lesen
  2. den messagebody (falls vorhanden) von Header trennen
  3. die Header aufsplitten und in Umgebungsvariablen setzen
  4. den body nach STDOUT umleiten
  5. die Response vom nachgelagerten Prozess aus STDIN lesen
  6. den ganzen Prozess von 1. bis 4. umkehren und die Response in das Socket schreiben

Aufgrund des Layers auf dem CGI/1.1 angesiedelt ist und seiner Einfachheit, wird CGI/1.1 auch als Low-Level-Schnittstelle bezeichnet. Das weitere Parsen eines Request anhand des gesendetetn CONTENT_TYPE ist Sache des Anwendungslayers. Der Webserver selbst also kennt keinen CONTENT_TYPE.

Mod_php, mod_perl, FastCGI u.a. Plugins ändern nichts am oben dargestellten Sachverhalt.

Anmerkung: In RFC3857 werden STDIN als standard input (4.2) und STDOUT als standard output (6.1) benannt.

Es kommt auch gar nicht auf einzlne Begriffe an sondern darum, den Zusammenhang zu verstehen. Jeder heutige Programmierer denkt in Layers und solche Modelle sind schon außerordentlich sinnvoll. Wesentlich also ist, daß das weitere Parsen eines Request den CGI/1.1 für den nachgelagerten Prozess aufgearbeitet hat eine Sache der Anwendung ist. So ist, wie @Rolf B schon schrieb, der Parser ein Teil des Scripts (also der Anwendung).

Parser in Perl wie z.B. CGI.pm gehen noch einen Schritt weiter in Richtung einer eigenständigen Klasse (OOP). Die Logik die in CGI.pm verbaut ist, basiert auf einem Default-Content-Type und das hat sich jahrzehntelang bewährt!

Mit freundlichen Grüßen!