multipart/form-data: Wie ein Formular-Upload auf der Leitung eingerahmt wird

Worum es geht

Eine Anfrage mit Content-Type: multipart/form-data; boundary=xYz hat einen Body wie:

--xYz
Content-Disposition: form-data; name="title"

Quarterly report
--xYz
Content-Disposition: form-data; name="file"; filename="q3.pdf"
Content-Type: application/pdf

%PDF-1.7 ...
--xYz--

RFC 7578 legt die Regeln fest. Teile werden durch CRLF, -- und die Boundary getrennt, die innerhalb keines Teils vorkommen DARF. Jeder Teil MUSS Content-Disposition: form-data mit einem name haben; ein filename SOLLTE Dateiinhalte begleiten, darf aber nicht blind verwendet werden, und jede darin enthaltene Verzeichnisangabe ist zu verwerfen. Mehrere Dateien für ein Feld werden als separate Teile mit demselben name gesendet; die ältere verschachtelte multipart/mixed-Form ist veraltet, sollte von Parsern aber weiterhin akzeptiert werden. Der Content-Type eines Teils ist optional und hat als Standard text/plain; die Textkodierung stammt aus einem charset-Parameter oder aus einem versteckten _charset_-Feld. Content-Transfer-Encoding ist für HTTP veraltet, und andere Content-*-Header müssen ignoriert werden. Teile mit demselben Namen DÜRFEN NICHT zusammengeführt werden, und die Reihenfolge bleibt erhalten. Nicht-ASCII-Dateinamen dürfen prozentkodiert sein, werden gewöhnlich als rohes UTF-8 gesendet, und die filename*-Form aus RFC 5987 DARF NICHT verwendet werden. Der HTML-Standard legt fest, wie Browser den Body zusammensetzen und den Boundary-String erzeugen.

Warum es wichtig ist

Anders als application/x-www-form-urlencoded kann jeder Teil einen Medientyp deklarieren und binäre Bytes tragen, ohne den um ein Drittel höheren Grössenaufwand von Base64 (vier Ausgabebytes pro drei Eingabebytes). Es ist das Format, das jeder Browser für <input type="file"> erzeugt und das die meisten Upload-APIs akzeptieren. Parser, die ganze Bodies im Speicher puffern, filename blind als Pfad übernehmen oder wiederholte Namen zusammenführen, sind eine wiederkehrende Quelle von Upload-Bugs und Schwachstellen.

So wird es angewendet

• Als Stream parsen: Teil für Teil lesen, Datei-Teile in temporären Speicher auslagern und Grössenlimits pro Teil und insgesamt durchsetzen, bevor Daten verarbeitet werden.
• Felder über den Parameter name referenzieren; filename als nicht vertrauenswürdigen Anzeigetext behandeln und einen eigenen Speichernamen erzeugen.
• Den Content-Type eines Teils als Hinweis behandeln und die Bytes validieren.
• Bei APIs Feldnamen, die sich wiederholen können, sowie Limits dokumentieren; JSON-Metadaten als eigenen Teil mit Content-Type: application/json senden, statt sie in einem Textfeld zu verstecken.
• In Clients die Bibliothek die Boundary und Content-Length erzeugen lassen; nicht von Hand zusammensetzen.

Stolpersteine

Nicht-ASCII-Feldnamen vermeiden; RFC 7578 empfiehlt einheitlich UTF-8, falls sie unvermeidlich sind. Trennzeichen sind CRLF; ein Parser, der auf blossem LF trennt, beschädigt binäre Teile. Frameworks, die Multipart bei jeder Anfrage vorschnell parsen, machen aus grossen Uploads einen Denial-of-Service-Pfad. Der charset von Textteilen fehlt oft, sodass das Charset des Formulars bekannt sein muss.