multipart/form-data : comment un envoi de formulaire est structuré sur le fil

Ce que c'est

Une requête avec Content-Type: multipart/form-data; boundary=xYz a un corps de cette forme :

--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--

La RFC 7578 énonce les règles. Les parties sont délimitées par CRLF, -- et la limite (boundary), laquelle NE DOIT PAS apparaître à l'intérieur d'une partie. Chaque partie DOIT porter un Content-Disposition: form-data avec un name ; un filename DEVRAIT accompagner le contenu d'un fichier, mais ne doit pas être utilisé aveuglément, et toute information de répertoire qu'il contient doit être supprimée. Plusieurs fichiers pour un même champ sont envoyés sous forme de parties distinctes portant le même name ; l'ancienne forme imbriquée multipart/mixed est obsolète, mais les analyseurs devraient continuer à l'accepter. Le Content-Type d'une partie est optionnel et vaut par défaut text/plain ; l'encodage du texte provient d'un paramètre charset ou d'un champ caché _charset_. Content-Transfer-Encoding est obsolète pour HTTP, et les autres en-têtes Content-* doivent être ignorés. Les parties portant le même nom NE DOIVENT PAS être fusionnées, et l'ordre est préservé. Les noms de fichiers non-ASCII peuvent être encodés en pourcentage, sont couramment envoyés en UTF-8 brut, et la forme filename* de la RFC 5987 NE DOIT PAS être utilisée. Le standard HTML précise comment les navigateurs assemblent le corps et génèrent la chaîne de limite (boundary).

Pourquoi c'est important

Contrairement à application/x-www-form-urlencoded, chaque partie peut déclarer un type de média et porter des octets binaires sans le surcoût de taille d'un tiers propre au base64 (quatre octets de sortie pour trois octets d'entrée). C'est le format que produit tout navigateur pour <input type="file">, et celui qu'acceptent la plupart des API de téléversement. Les analyseurs qui mettent en mémoire tampon des corps entiers, font confiance à filename en tant que chemin, ou fusionnent des noms répétés, sont une source récurrente de bogues et de vulnérabilités liés aux téléversements.

Comment l'appliquer

• Analyser en flux : lire partie par partie, déverser les parties de fichier vers un stockage temporaire, et imposer des limites de taille par partie et au total avant de consommer les données.
• Indexer les champs par le paramètre name ; traiter filename comme un texte d'affichage non fiable et générer son propre nom de stockage.
• Traiter le Content-Type d'une partie comme une indication, et valider les octets.
• Pour les API, documenter les noms de champs, qui peuvent se répéter, ainsi que les limites ; envoyer les métadonnées JSON dans leur propre partie avec Content-Type: application/json plutôt que de les dissimuler dans un champ texte.
• Côté client, laisser la bibliothèque générer la limite (boundary) et Content-Length ; ne pas concaténer à la main.

Pièges

Éviter les noms de champs non-ASCII ; la RFC 7578 recommande l'UTF-8 de façon uniforme s'ils sont inévitables. Les délimiteurs sont des CRLF ; un analyseur qui découpe sur un simple LF corrompt les parties binaires. Les frameworks qui analysent le multipart de façon systématique à chaque requête transforment les téléversements volumineux en vecteur de déni de service. Le charset des parties textuelles est souvent absent, si bien que le charset du formulaire doit être connu par ailleurs.