1unitedpower: multipart/form-data

Beitrag lesen

--boundary
Content-Type: image/gif name="bild" filename="foo.gif"

BINARY
--boundary

und das wird insofern umständlich als dass der Parser über die BINARY hinaus lesen muss, solage nämlich bis er wieder eine --boundary im Puffer hat.

Die meisten Parser benutzen dafür sogenannte Tokenizer, die den Text in logische Einheiten gliedern. In diesem Fall, könnte ein Tokenizer den Text beispielsweise so zerlegen:

--boundary
Content-Type: image/gif name="bild" filename="foo.gif"

BINARY
--boundary

Diese Tokens benutzt der Parser dann als Eingabe und ergänzt die nötige Struktur. In dem konkreten Beispiel würde ein Tokenizer vermutlich auch noch gleich die Header-Daten der Formular-Fragmente zerlegen.

Das bis dahin Gelesene ist also um die Länge der Boundary zu kürzen und der Pointer im Handle um diesen Betrag zurückzusetzen. Schöner wärs doch, wenn es zu jedem Part einen Eintrag

--boundary
Content-Length: 522

geben würde, dann stehts von vornherein fest, wieviele Bytes zu lesen sind.

Es gibt Kodierungen, wie bswp. PHPs serialize() die machen das wirklich so. Für die Formularkodierung wäre das ungünstig: Wenn große Datenmengen übertragen werden sollen, würde der Upload-Vorgang verzögert werden bis die Datenmenge ermittelt ist. Gerade bei kontinuirlichen Datenströmen, deren Größe man nicht im Voraus kennt, ist das ein Problem, weil man eigentlich schon während des Lesens des Streams parallel Daten hochladen könnte.

Frage an die Experten: Werden zukünftige Browser oder XHR eine Content-Length in solchen Fällen liefern? In der Tat wäre ein Parser einfacher zu programmieren.

Parser sind heutzutage schon so weit erforscht, dass man sie vollautomatisch aus Spezifikationen der Sprachsyntax erzeugen lassen kann. Solche Spezifikation liegen meistens als kontextfreie Grammatiken vor, damit lassen sich die Parser-Generatoren füttern und heraus kommen einsatzbereite Parser.