Versionen dieses Beitrags

multipart/form-data

pl
  • multipart/form-data
  • Tach!
  • >
  • > > Und es zeigte sich auch beim Entwickeln des Parsers in C für diesen Enctype der Designfehler dessen der darin besteht, daß es keine Längenangabe für die value-Parts gibt.
  • >
  • > Wenn das ein Designfehler sein soll, so sind auch alle anderen Datenformate ein Designfehler, die keine vorangestellte Längenangabe haben.
  • Eine solche Verallgemeinerung ist Unsinn! Aber was den Enctype multipart/form-data betrifft, ist es ein Designfehler der nicht gerade trivial ist. So muss man die gesamte Binary in Schritten von 1 byte lesen, was sich negativ auf die Performance auswirkt.
  • Am Binary Part angekommen (nach jeder Leerzeile), wird man einen Puffer mit der Größe CONTENT_LENGTH anlegen müssen damit kein Pufferüberlauf entsteht. Da CONTENT_LENGTH die Länge des gesamten POST ist, führt das dazu, daß, je nach Anzahl der Parts, der Speicherbedarf ein Vielfaches von CONTENT_LENGTH betragen kann. Mann könnte den Puffer um die Länge der Boundary kürzer anlegen aber das sind nur um die 40..50 Bytes.
  • So wird die Binary dann Byte für Byte in den Puffer gelesen solange bis die Boundary am Ende dieses Puffers erscheint. Das heißt, man muss das nach jedem Byte prüfen, was auch wieder very schlecht für die Performanze ist.
  • Und schließlich muss man die Boundary am Ende des Puffers wieder abschneiden.
  • Hätte man für jeden Part eine Längenangabe, wäre der Algorithmus viel einfacher, performanter, CPU und RAM gefälliger.
  • Beim Default Enctype ergibt sich ein ähnliches Bild. Insbesondere die Prozentkodierung wirkt sich bei großen Datenmengen schlecht auf die Performance aus.
  • Und ja, da hast Du Recht, XML, CSV, JSON u.a. Enctypes sind allesamt ineffizient für den Datentransport. Man kann nämlich jeden sequentiellen Serializealgorithmus in jeder Programmiersprache implementieren: Maschinenlesbar, Effizient und Plattformübergreifend!
  • Diese Aussage kann jeder bestätigen der mal selbst ein paar Serializer entwickelt hat die sequentiell arbeiten. Meine Serializer für verschiedene Enctypes (Content-Type) funktionieren übrigens in JavaScript, PHP, Perl und in C gleichermaßen.
  • Und was wäre ein FW, wenn der Parser nicht erweiterbar wäre um weitere Enctypes!
  • MfG
  • MfG
  • PS: multipart/form-data ist von allen anderen Enctypes der Grottigste!