Email: Request-Header Content-Type und XHR

Beitrag lesen

There is no default value for this variable. If and only if it is unset, then the script MAY attempt to determine the media type from the data received. If the type remains unknown, then the script MAY choose to assume a type of application/octet-stream or it may reject the request with an error (as described in section 6.3.3).

Fett von mir.

Der Parser ist Teil des Scripts. Wenn CONTENT_TYPE nicht gesetzt ist, DARF das Script an den Daten schnuppern und versuchen, einen enctype zu erraten. Gelingt das nicht oder will es das nicht, DARF das Script die Daten als octet-stream interpretieren oder den Request abweisen.

Nun, ich kenne keinen Parser der sich so verhält. Wie sich PHP verhält hab ich schon geschrieben. Das CGI.pm von Perl nimmt für den Fall daß kein CONTENT_TYPE vorliegt den Default Enctype an, egal ob die Daten aus dem QUERY_STRING oder aus STDIN gelesen werden.

Der Default ist application/x-www-form-urlencoded.

Die Parser die ich programmiert habe entscheiden im Gegensatz zu CGI.pm anhand CONTENT_LENGTH wo die zu parsenden Daten zu finden sind, also entweder in STDIN oder im QUERY_STRING unabhängig von der Requestmethode.

Insgesamt ist die Frage der Logik eine praktische Frage und da macht der Default application/x-www-form-urlencoded schon einen Sinn. Keinen Sinn hingegen macht es für einen Parser einen Default application/octet-stream anzunehmen, weil es praktisch keinen Browser gibt welcher diesen Enctype sendet und dieser Enctype von vornherein ausschließt daß strukturierte Daten vorligen. Ungemein praktisch ist es, den Parser als eine eigenständige Klasse anzulegen und diesen erweiterbar zu machen für beliebige Content-Types. CGI/1.1 umfasst ja nicht nur STDIN und den QUERY_STRING, auch Customheader sind Parameter die zum Request gehören.

MFG