Vielen Dank für Deine Ausführungen. Wir werden sehen, was das bringt. Wesentlich ist nicht zu zeigen, dass Perl eine tolle Programmiersprache ist, sondern zu zeigen, was man mit Perl Tolles machen kann (Zielorientierung).

Zurück zum CGI.pm das schleppt ungezählte Altlasten mit sich rum und das seit Jahren. Da wird ein Haufen Code kompiliert der am Ende gar nicht gebraucht wird. Absolut unlogisch ist es, PUT/POST Daten in param('PUTDATA') bzw, param('POSTDATA') zu erwarten, wenn der Enctype nicht application/x-www-form-urlencoded ist.

Logischer ist nach dem Standard CGI/1.1:
1) stehen Daten/Parameter in STDIN, setzt der Webserver eine Umg. Variable CONTENT_LENGTH
2) stehen Daten/Parameter in STDIN ist das unabhängig von der Request-Methode
3) Parameter können unabhängig von der Request-Methode in QUERY_STRING vorhanden sein
4) wie Parameter zu parsen sind ist nicht Bestandteil des Standards, das legt höchstens der gesendete CONTENT_TYPE fest

CGI.pm räumt STDIN gnadenlos ab, im Fall des Default Content-Type, gibt es überhaupt keine Möglichkeit, an die gesendeten Daten heranzukommen. Es sei denn die Daten sind entsprechend Default serialisiert.

Aus diesen Gründen sollte ein Parser einen von Request-Methode unabhängigen und ebenfalls vom Content-Type unabhängigen, also unbedingten Zugriff auf die gesendetetn Daten erlauben. Hierzu kopiert mein eigenes Modul die Daten von STDIN nach IO::String.

Was übrigbleibt ist ein Parsen entsprechend des gesendeteten Content-Type. Und von der Logik her liefert param() False, wenn der Content-Type: application/octet-stream ist.

Aus Kompatibilitätsgründen wird bei fehlendem Content-Type ebenfalls der bisherige Default angenommen. So habe ich meine Eigenentwicklung xCGI.pm genannt und das Erste was auffällt ist ein spürbarer Ruck der Performance nach oben ;)

Schönen Sonntag.
Last edited: 2016-02-21 09:56:01 +0100 (CET)