Quote

Dass man einen skalaren Kontext erzwingen kann, steht ja gar nicht zur Diskussion.

Doch genau darum geht es!

Siehe auch meinen Hinweis auf localtime(). Daß Perl Hashes auch nur Arrays sind, vermittelt jeder Grundkurs in Perl. Und genau deswegen sind zusätzliche Funktionen die Mojo mitbringt um den Listenkontext zu erzwingen überflüssig: Weil es das mit scalar() schon lange gibt.

Und auch darum geht es:

In CGI.pm jedoch ist eine Logik verbaut, die Weiterentwicklungen verhindert, das ist das eigentliche Problem an CGi.pm: Es ist nicht skalierbar. Lt. HTTP RFC ist ein messagebody zu erwarten, wenn ein Header Content-Length > 0 gesendet wurde und das ist unabhängig von der Requestmethode.

Mit CGI.pm auf PUT-Daten zuzugreifen ist jedoch nur möglich wenn ein Content-Type != application/x-www-form-urlencoded gesendet wurde -- Was für eine seltsame Logik!!!

POST_MAX ist genauso auch unsinnig. Weil es eben auch möglich ist, mit anderen Requestmethoden einen messagebody zu senden, ist es blödsinnig einen zu großen messagebody an einer bestimmten Request-Methode festmachen zu wollen: http://rolfrost.de/postmax.html


In Mojo stecken sicher gute Gedanken die mit diesem und anderen in CGI.pm verbauten Unfug Schluss machen, aber einen eigenen Parser zu entwicklen der CGI/1.1 RFC gerecht implementiert ist ja nun auch keine Hexerei; mit der richtigen Idee ist das nur Tipparbeit.

Mein Parser http://rolfrost.de/parser.html bindet die zum Layer (Content-Type) gehörigen Libraries übrigens auch nur dann ein, wenn sie tatsächlich gebraucht werden -- compiled by demand.

Und was die maximale länge eines messagebodies betrifft, ist bei meinem FW konfigurierbar und zwar für jede Seite unabhängig und unabhängig von der Requestmethode. Wobei es natürlich einen zentral konfiguierten Default gibt.

Es kam schon immer darauf an die eigentlichen Probleme zu erkennen die oftmals weitab von dem liegen was heise & Co verbreiten.

MfG

PS: Siehe auch http://rolfrost.de/mfup.html und http://rolfrost.de/content_type.html
Last edited: 2018-03-20 06:55:31 +0100 (CET)