Multiple File-Upload mit Enctype Multipart/Form-Data und Perl

Gewöhnlich wird das Perl-Modul CGI.pm dafür eingesetzt. Der Algorithmus hat es in sich.

Untenstehendes Formular demonstriert die Wirkungsweise meines Perl-Moduls ParseMultipart.pm

Sie dürfen mehrere Dateien auswählen:

Hinweis: Die hochgeladenen Dateien werden serverseitig nicht gespeichert! Die Datenmenge ist begrenzt auf ca. 10MB. Nach dem Upload zeigt Ihnen eine Tabelle Details zu den hochgeladenen Dateien. Das Perl-Modul stellt serverseitig für jede hochgeladene Datei ein Handle bereit.

Vorteile gegenüber CGI.pm

Mein Modul ParseMultipart.pm ist ein unabhängiger Layer und dient, wie der Name schon sagt, lediglich dazu, den Content-Type: multipart/form-data zu parsen. Mein Modul verzichtet auf temporäre Dateien und ist sehr einfach in der Handhabe. Informationen zu hochgeladenen Dateien wie der Original Dateiname, Content-Length und Content-Type sind serverseitig recht einfach abrufbar. Die hochgeladenen Dateien liegen in einem Handle vor und können unmittelbar weiterverarbeitet werden. Der Compile-Overhead für das Modul ist wesentlich geringer als bei CGI.pm. Und hier ein Anwendungsbeispiel für ParseMultipart.

Algorithmus zum Parsen des Upload-Streams

Sendet ein Browser POST-Daten, setzt der Webserver eine Umgebungsvariable CONTENT_LENGTH, welche die Anzahl der gesendeten Bytes angibt. Dies sendet bereits der Client (Browser, Useragent) in einem gleichnamige Request-Header. Über den Common Gateway stellt der Webserver die Daten für ein CGI-Script an STDIN bereit. Ab hier kommt der Parser ins Spiel, er wird den Datenstrom aufnehmen und die darin enthaltenen Einzelteile wiederherstellen.

Als Erstes zieht der Parser die Boundary-Sequenz aus dem Handle. Was dann an Daten übrigbleibt, beinhaltet eine zyklische, also eine sich wiederholende Struktur. Untenstehend der weitere Ablauf innerhalb des Schleifenkörpers:

In meinem Perl-Modul, Link zur Source siehe obenstehend, ist genau dieser Algorithmus abgebildet.

Über den Umgang mit Parametern im HTTP Request

Gewöhnlich wird zur Verarbeitung von Parametern das Perl-Modul CGI.pm eingesetzt. Es ist hoffnungslos veraltet und bildet im Zusammenhang mit der Request-Methode eine Logik ab, die nicht immer sinnvoll ist. Aus diesen Gründen verzichtet mein Framework auf den Einsatz CGI.pm vollständig und verwendet einen von Request-Methoden unabhängigen Layer, welcher in erster Linie den vom HTTP-Client gesendeten Content-Type (Enctype) untersucht. Erst in einem zweiten Schritt wird untersucht, welche Quelle für den Common Gateway in Frage kommt. In Fakt können Daten bei jeder beliebigen Request-Methode an STDIN anstehen, das ist nicht nur auf POST oder PUT beschränkt. Darüber hinaus kann es auch bei jeder beliebigen Request-Methode Daten bzw. Parameter im URI (QUERY_STRING) geben, auch das ist nicht nur auf Request-Method GET beschränkt.

Abstrakt gesehen handelt es sich bei Parametern um strukturierte Daten. Untenstehend eine Auswahl derjenigen Enctypes, die für eine Stukturierung möglicherweise eingesetzt sind:


Anbieter: nmq​rstx-18­@yahoo.de, die Seite verwendet funktionsbedingt einen Session-Cookie und ist Bestandteil meines nach modernen Aspekten in Perl entwickelten Frameworks.