Générateur et analyseur multipart/form-data

Ce qu’est multipart/form-data

multipart/form-data est le format qu’un navigateur emploie pour envoyer un formulaire contenant un fichier. Au lieu d’une seule chaîne de paires clé-valeur, le corps est découpé en parties séparées par un délimiteur appelé frontière, et chaque partie porte ses propres en-têtes. Toute partie doit déclarer Content-Disposition: form-data avec un paramètre name indiquant de quel champ elle provient ; celle qui représente un fichier ajoute un paramètre filename et, le plus souvent, un Content-Type.

La frontière est le seul paramètre obligatoire de l’en-tête Content-Type de la requête, car sans elle un destinataire n’a aucun moyen de savoir où une partie s’arrête et où la suivante commence. Ce doit être une chaîne qui n’apparaît dans aucune partie, et la spécification MIME la plafonne à 70 caractères. D’où les valeurs longues et d’allure aléatoire que produisent les vrais navigateurs, plutôt que quelque chose de lisible.

Deux détails du format piègent tout le monde parce qu’ils ressemblent à du bruit de mise en forme. Les fins de ligne sont des paires CRLF et non des sauts isolés, partout, y compris la ligne vide qui sépare les en-têtes d’une partie de son contenu. Et le délimiteur final porte deux tirets supplémentaires : c’est ce qui dit que le corps s’est terminé plutôt que d’avoir été coupé en route.

Comment s’en servir

1. Choisissez un mode. Composer une requête prend un champ texte et un champ fichier et écrit les octets qu’un navigateur enverrait. Lire une requête prend un corps dont vous disposez déjà et en déduit les parties qu’un serveur en tire.
2. En mode composition, tapez le nom de fichier qui vous intéresse. Les boutons d’exemple couvrent un nom simple, un nom accentué, un nom impossible à restituer et un nom contenant un guillemet double. Regardez la ligne en dessous : elle montre comment chaque nom circule, et si la transformation peut être annulée.
3. En mode lecture, collez le corps et la frontière. Vous pouvez coller l’en-tête Content-Type entier, la frontière en sera extraite. Le tableau énumère chaque partie reçue ; les constats se répartissent en erreurs, qui cassent quelque chose ; avertissements, qui signalent une requête non produite par un navigateur ; et remarques, utiles à connaître et sans faute.

Trois spécifications, trois réponses sur le nom du fichier

Demandez comment placer un nom de fichier hors US-ASCII dans un envoi et vous obtenez trois réponses incompatibles, toutes normatives — et cette page existe parce que la première vers laquelle chacun se tournerait est explicitement interdite.

La RFC 7578 tranche dans une note : l’encodage de la RFC 5987, celui qui ajouterait un paramètre filename* à l’en-tête Content-Disposition, ne doit pas être employé ici. C’est exactement l’inverse de la règle pour un téléchargement. Dans une réponse HTTP, la RFC 6266 exige filename* pour tout nom que l’US-ASCII ne sait pas écrire, et ce site consacre une page séparée à le faire correctement. Même en-tête, même paramètre, instruction opposée — et la seule chose qui décide laquelle s’applique est le sens de circulation.

La même section propose ensuite une deuxième réponse : les noms de fichier peuvent être encodés en pourcentage, à la manière d’une URI file:. Et au paragraphe suivant elle concède la troisième, celle qui a réellement cours : des systèmes largement déployés envoient les noms avec des octets hors US-ASCII directement, en UTF-8 le plus souvent. Cette concession mérite deux lectures, car une spécification qui reconnaît que la pratique fait autrement est une spécification qui vous dit ce que votre code va recevoir.

Ce que font les navigateurs, c’est la troisième. Le standard HTML définit l’algorithme qu’ils suivent : le nom part en octets bruts dans l’encodage du formulaire, sans aucun paramètre pour l’annoncer. Un destinataire qui devine mal produit donc du mojibake, et rien dans la requête ne permet de le corriger. Le générateur fait ici ce que fait un navigateur, et la ligne en dessous montre le compte d’octets devancer le compte de caractères : cette décision rendue visible.

L’échappement ne peut pas être annulé

L’algorithme du standard HTML échappe exactement trois caractères dans un nom de champ ou de fichier : un saut de ligne devient %0A, un retour chariot %0D et un guillemet double %22. Puis il ferme la liste en toutes lettres : l’agent utilisateur ne doit effectuer aucun autre échappement.

Cette dernière clause est la plus intéressante, car elle signifie que le signe pour cent n’est jamais touché. Un fichier réellement nommé a%0Ab.txt et un fichier dont le nom contient un vrai saut de ligne arrivent tous deux sous la forme a%0Ab.txt, et rien dans la requête ne les distingue. Même chose pour %0D face à un retour chariot et pour %22 face à un guillemet. Mesuré contre une implémentation réelle de l’algorithme plutôt que déduit : les trois paires ressortent identiques.

La transformation est donc à sens unique par construction, et la réparation évidente — échapper aussi le pourcentage — est précisément ce que la norme interdit. Tout ce qui enregistre un fichier reçu sous le nom fourni suppose en silence que cela n’arrive jamais. C’est rare, et ce n’est pas impossible : un pourcentage suivi de deux chiffres hexadécimaux est exactement la forme que prend un nom déjà passé par un encodage d’URL en amont.

L’outil le signale au lieu de le corriger, car il n’y a rien à corriger. Lorsqu’un nom partage ses octets avec un autre, la ligne en dessous le dit, et le lecteur décide si cela compte pour ce qu’il construit.

Ce que ceci ne vous dira pas

Ceci lit le texte que vous collez et rien d’autre. Un navigateur ne peut pas inspecter les requêtes d’un autre site : l’outil ignore donc si le corps sous vos yeux est celui qui part, si l’en-tête Content-Type qui l’accompagne concorde, et ce qu’un serveur en a fait ensuite.

Le générateur écrit un corps, pas une requête. Il affiche l’en-tête Content-Type qui doit l’accompagner, puisque la frontière y réside et que le corps n’a aucun sens sans elle, mais le reste — la méthode, le chemin, la longueur — vous appartient. Collez le corps dans le client avec lequel vous testez plutôt que d’attendre que ceci envoie quoi que ce soit.

Une simplification est assumée. Le contenu réel d’une partie est fait d’octets, et un navigateur y place volontiers un JPEG ; ceci travaille en texte, donc la partie fichier porte un contenu factice. Tout le reste — la structure, les en-têtes, l’échappement et les délimiteurs — est exactement ce que produit un navigateur, et c’est le sujet de la page ; mais ne mesurez pas la taille d’un envoi réel sur ce que vous voyez ici.

Enfin, le format comporte un mécanisme ancien que ceci n’implémente pas : Content-Transfer-Encoding, qui permettait autrefois qu’une partie soit en quoted-printable pour survivre à un transport sept bits. La RFC 7578 demande aux émetteurs de ne pas en générer sur un transport qui achemine du binaire, ce que fait HTTP : l’outil le signale donc si vous en collez un, plutôt que de faire comme si c’était normal.

Pourquoi est-ce gratuit ?

Composer et relire un corps de requête relève du traitement de texte et s’exécute dans votre navigateur. Aucun serveur n’intervient : rien à facturer, aucun compte à créer.

Rien n’est envoyé et rien n’est conservé. Rechargez la page et elle aura oublié ce que vous avez collé.