Résumé

  • La révision de 2015 interdit de fusionner les parties portant le même nom et de réordonner les résultats dans les intermédiaires. Recevoir toutes les données ne suffit donc pas à les conserver dans l’application.
  • Le parcours des spécifications auxquelles Larry Masinter a contribué distingue la fidélité du format, le sens métier et l’autorisation de traiter un fichier.

Un formulaire n’a pas toujours une seule réponse par nom de champ. Deux justificatifs peuvent, par exemple, appartenir au même champ de dépôt. Leurs deux parties sont alors distinctes, même si leurs noms sont identiques. Transformer immédiatement l’ensemble en une table ne gardant qu’une valeur par nom peut faire disparaître un document sans que la transmission ait échoué. Ce cas est une illustration analytique, et non un incident constaté. Il permet de lire les travaux de Larry Masinter autrement que comme l’histoire d’un bouton permettant de joindre un fichier.

De la proposition à l’entretien d’un standard

En novembre 1995, E. Nebel et L. Masinter publient le RFC 1867. Les formulaires HTML ordinaires ne disposent pas alors d’un mécanisme uniforme pour demander des fichiers locaux. Leur proposition associe la sélection d’un fichier à une représentation compatible avec MIME, en prévoyant aussi une transition pour les anciens navigateurs. Le texte est de catégorie Experimental : il ne prétend pas constituer une norme Internet.

Le RFC 2388, signé L. Masinter en août 1998, relève du Standards Track. Le RFC 7578, publié en juillet 2015, le remplace. Il porte le même nom d’auteur, mais son statut précise qu’il résulte du consensus de la communauté IETF après examen public. Il faut donc reconnaître une contribution durable sans attribuer à Masinter seul les pratiques des navigateurs ou les fondations de MIME. Sa page personnelle ancienne, datée de 2014, apporte un contexte historique et une photographie de référence ; elle n’établit pas son poste actuel.

Le corps multipart est une succession de parties séparées par une délimitation. Chacune indique le nom du champ d’origine dans son en-tête Content-Disposition de type form-data. Texte et contenu de fichier peuvent ainsi voyager ensemble tout en restant distinguables. Le texte de 2015 dépasse expressément HTML et HTTP : il vise aussi d’autres applications, y compris celles où personne ne remplit un formulaire à l’écran.

Ce que la version de 2015 précise

La section 5.5 du texte de 1998 ne définit ni la relation entre l’ordre des champs et celui des valeurs renvoyées, ni le traitement des champs de même nom. En 2015, la section 5.2 établit des règles plus nettes. Pour les formulaires dont l’ordre est bien défini, les processeurs devraient renvoyer les résultats dans cet ordre. Les intermédiaires ne doivent pas les réordonner ; les parties de même nom ne doivent pas être fusionnées. La première règle est une recommandation normative, pas l’obligation de donner un ordre naturel à tout formulaire imaginable.

La répétition n’est d’ailleurs pas nécessairement anormale. Selon la section 4.3, plusieurs fichiers d’un même champ doivent être transmis dans des parties séparées portant ce même nom. L’ancienne représentation imbriquée multipart/mixed est dépréciée au profit de la pratique largement déployée. Le texte recommande toutefois aux récepteurs destinés à un usage large de reconnaître aussi l’ancien procédé. Un standard entretenu doit clarifier la sortie sans supposer que toutes les entrées anciennes ont disparu.

Une interface applicative peut ensuite choisir un seul élément si son schéma l’exige et si elle a vérifié ce qu’elle a reçu. Le risque se situe avant cette décision : une conversion qui élimine la multiplicité prive le métier de la possibilité de l’examiner. À l’inverse, conserver deux parties n’autorise pas automatiquement deux opérations. La fidélité de la représentation ne remplace pas une règle d’acceptation.

Trois noms, trois responsabilités

Le nom du champ désigne une place dans la soumission. Le nom de fichier est une autre information. Le RFC 7578 recommande de le fournir pour un fichier, mais admet son absence s’il est indisponible, sans signification ou privé. Le récepteur ne doit ni le reprendre aveuglément comme destination locale, ni utiliser les informations de chemin qu’il peut contenir. Un flux issu d’un appareil n’a pas besoin d’un faux nom de fichier de bureau pour être recevable.

Les caractères introduisent une autre difficulté de migration. Le texte conseille des noms de champ ASCII pour faciliter l’interopérabilité et un usage uniforme d’UTF-8 lorsqu’un nom non ASCII est inévitable. Il décrit des conventions de jeu de caractères par défaut et reconnaît la diversité des anciens encodeurs. Le paramètre filename* est interdit dans ce format : une règle provenant d’un autre contexte d’en-tête ne peut pas être importée sans examen.

Enfin, multipart ne fournit pas de mécanisme reliant intrinsèquement les données au formulaire qui les a produites. Le contexte relève de l’application, par exemple de sa destination de traitement ou de données qu’elle fournit. Ni la confidentialité ni l’intégrité ne sont garanties par la structure. Dès 1995, les auteurs mettent en garde contre l’envoi de fichiers locaux non demandés par l’utilisateur. En 2015, le texte aborde également les divulgations involontaires, l’écrasement de fichiers et les contenus exécutables. Une analyse syntaxique réussie ne résout aucun de ces problèmes à elle seule.

Périmètre des preuves

Les sources sont les trois RFC liés ci-dessus et la page personnelle datée. Aucune enquête sur les bibliothèques actuelles, aucun taux de perte et aucun test d’attaque ne sont présentés. Les conséquences opérationnelles relèvent d’une analyse éditoriale. La photographie publique sert à ancrer le portrait éditorial généré par IA ; le décor de travail est inventé, sans prétendre représenter un bureau réel.