Content-Type: multipart/form-data ist total veralteter Schrott

Seit moderne Browser mit Binaries umgehen können, gibt es wesentlich effizientere Alternativen

Bis heute kennen Browser nur 3 Content-Types zum Senden von Daten in Richtung Webserver:

Wobei Letzterer wohl kaum genutzt wird, weil die Daten völlig unstrukturiert sind. Dementsprechend können serverseitige, in Perl, PHP u.a. Programmiersprachen übliche Parser nur mit den ersten beiden Content-Types umgehen, d.h., anhand des im Request-Header gesendeten Content-Types den Inhalt wiederherstellen. Multipart/form-data ist bis heute der einzige Content-Type, welcher das Senden von Binaries erlaubt, beispielsweise das Hochladen von Dateien über den Browser. Dieser Enctype hat erhebliche Einschränkungen und ist schwierig bzw. aufwändig zu parsen.

Einschränkungen in multipart/form-data

Für jeden einzelnen Part stehen folgende Attribute zur Verfügung (mit Beispiel):

Somit ist es also nicht möglich, eigene bzw. weitere Attribute hinzuzufügen. Darüber hinaus wird das Attribut filename="dateiname.ext" vom Browser selbst angehängt, sofern es sich um ein im Formular eingefügtes Attachment handelt. Das JavaScript-Objekt FormData nimmt ebenfalls den lokalen Dateinamen oder setzt den Wert für dieses Attribut auf filename="blob" wenn ein Inhalt vom Datentype blob anhänglich ist.

Parsen des Enctype multipart/form-data

Wenn anhand er Boundary gesplittet wird, läuft der gesamte Prozess zur Wiederherstellung der Einzelparts komplett im Hauptspeicher ab. Eine andere Möglichkeit ergibt sich infolge sequentielles Lesen aus dem Gateway i.d.R. STDIN (CGI/1.1). Haltepunkte ergeben sich aus der Leerzeile und der Boundary zwischen den einzelnen Parts und es muss in Schritten von 1-Byte gelesen werden, was diesen Prozess nicht gerade performant macht -- Wenn es eine Längenangabe für den eigentlichen Content geben würde, könnte ein Parser wesentlich performanter arbeiten. Wurde die Boundary schließlich erkannt, muss die bis dahin gelesene Binary um diese Sequenz wieder gekürzt werden. Hier ein Perl-Modul was mit dem beschriebenen Algorithmus arbeitet.

All diese Nachteile, die auch auf eine gewisse Rückständigkeit in der Entwicklung von Internet-Standards hindeuten, sind seit Jahren überwindbar, selbst JavaScript kann mittlerweile mit reinen Binaries umgehen. Somit ergeben sich je nach Herangehensweise ganz andere Möglichkeiten, die gegenüber multipart/form-data wesentlich effizienter, performanter, skalierbarer und vor Allem zukunfstorientierter sind:

Schwerwiegender Designfehler

Dieser Enctype übermittelt nicht die Länge der lokal im Browser eingelesenen Dateien. Ich halte dies für einen schwerwiegenden Designfehler welcher im Übrigen das Parsen fast in Frage stellt und es ziemlich umständlich macht. Wenn die Größe übermittelt würde, wäre der Prozess des Parsen wesentlich einfacher umzusetzen!

Abstrakte Datentypen

Content-Type: multipart/form-data abstrahiert einen Datentyp mit untenstehender Struktur:

[{Attribute => Value},{},{},...]
# in Perl ein Array mit Hash-Referenzen

Wobei die Schlüssel-Werte-Paare {Attribute => Value} namentlich und von der Anzahl her vorgegeben sind, siehe weiter oben. Nicht vorgegeben ist die Anzahl der einzelnen Parts dieser Multipart-Message. Da es keinen Grund gibt, die Anzahl und Namen der Attibute für einen Einzelpart von vornherein festzulegen, kann dies natürlich auch variabel gestaltet sein.

Gut durchdachte Serialize-Algorithmen kodieren Offset-Angaben binär als 32Bit-Integer. Das Dateiupload mit einem Solchen Serializer demonstriert diese Anwendung als Beispiel dafür, dass es effizientere Alternativen für den Content-Type: multipart/form-data gibt.

Alternativen zu diesem Enctype

Dieser Artikel beschreibt eine sehr praktische Alternative, ich habe diesen Enctype der die FileAPI moderner Browser konsequent nutzt, multipart/slice-data genannt. Gleichzeitig habe ich das Perl Modul CGI.pm in diser Hinsicht überarbeitet und hierzu ein Schichtenmodell entwickelt welche die Aufgaben der einzelnen Layer klar definiert.

Die FileAPI moderner Browser nutzend (was FomData nicht tut!) werden mit meinem neuen Enctype auch die Dateilänge und LastModified übertragen. Ein Austausch der Enctype Layer wirkt sich nicht auf den Anwendungscode aus.


Die rein persönlichen Zwecken dienende Seite verwendet funktionsbedingt einen Session-Cookie. Datenschutzerklärung: Auf den für diese Domäne installierten Seiten werden grundsätzlich keine personenbezogenen Daten erhoben. Das Loggen der Zugriffe mit Ihrer Remote Adresse erfolgt beim Provider soweit das technisch erforderlich ist. @: Rolf Rost, Am Stadtgaben 27, 55276 Oppenheim, nmq​rstx-18­@yahoo.de