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:

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.


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