pl: irgendein anderes Thema

Beitrag lesen

problematische Seite

Hi,

Perl lebt, Perl ist tot, ja es stimmt Beides. Betrachte CGI.pm, die meisten Perl-Entwickler binden das nur ein, um Parameter parsen zu können. Dafür kennt dieses Modul lächerliche 2 Content-Types:

application/x-www-form-urlencoded und multipart/form-data

so als wäre die Entwicklung seit 20 Jahren stehengeblieben. CGI.pm ist tot, toter geht nicht. Aber davon abgesehen ist multipart/form-data auch Schrott, das war es schon immer. Täglich landen rund 50 neue Module auf CPAN, auch neue Frameworks sind dabei.

Aber seit 20 Jahren gibt es zu CGI.pm keine Alternative, zumal es jede Menge neue Content-Types gibt, xml, json usw. die in den letzten 20 Jahren hinzugekommen sind. Angesichts dieser ungeheuerlichen Schieflage frage ich mich, was Entwickler eigentlich von Perl 6 erwarten -- Ein Wunder vielleicht!?

Dabei ist es geradezu ein Witz, die Parameter eines Enctype="application/x-www-form-urlencoded" zu parsen und als Erweiterung auf andere Enctypes wären lediglich die entsprechenden Module einzubinden -- Alles liegt griffbereit auf CPAN nur: Es kommt keiner auf die Idee, CGI.pm entsprechend zu erweitern und dafür den unnützen Ballast wegzuschmeißen den CGI.pm seit Jahrzehnten mit sich rumschleppt und den ohnehin kaum jemand nutzt.

Die File-API moderner Browser macht multipart/form-data überflüssig. Ne, CGI.pm brauche ich schon lange nicht mehr. Zumal nicht einmal die Request-Method darüber entscheidet, ob Daten serverseitig aus STDIN gelesen werden müssen sondern einzig der Header Content-Length. Komisch, dass das noch niemanden weiter aufgefallen ist, die ganze Logik in CGI.pm geht an der Schnittstellendefinition CGI/1.1 glatt vorbei und das seit Jahrzehnten.

Und welcher Webserver ist schon so strikt konfiguriert, dass er nur RFC-gerechte Request-Methoden zulässt?

Na, ich werd' mal den Artikel angehen...