Résumé

  • RFC 1867 puis RFC 2388 représentaient plusieurs fichiers issus d’un champ par une partie multipart/mixed nichée dans multipart/form-data.
  • RFC 7578 indique qu’aucun émetteur utilisant cette méthode n’était connu, recommande une partie externe par fichier avec le même nom de champ et conserve une attente de compatibilité pour les récepteurs.

Du formulaire au corps de requête

Avant qu’un navigateur puisse transmettre les fichiers choisis au moyen d’un mécanisme commun, il fallait souvent une application cliente spécialisée. Le RFC 1867 de 1995 proposa un contrôle HTML INPUT TYPE=FILE et une représentation MIME mêlant champs ordinaires et contenu de fichiers. Le texte avait le statut Experimental : il ne prétendait pas encore fixer une norme Internet achevée. Il envisageait même une transition pour les agents utilisateurs incapables de faire un tel envoi.

Le dessin retenu séparait les rôles. La partie externe multipart/form-data portait le nom du champ du formulaire. Pour plusieurs fichiers sélectionnés dans ce seul champ, une partie multipart/mixed interne contenait les fichiers. Ce choix transformait une collection en objet emboîté, au lieu de répéter le champ dans le flux extérieur.

RFC 2388, publié en 1998 comme document Standards Track, généralisa le type de média au-delà d’HTML et de HTTP : d’autres applications pouvaient s’en servir pour retourner les valeurs d’un formulaire. Mais, pour un champ contenant plusieurs fichiers, il conserva la partie multipart/mixed imbriquée. Une proposition s’était muée en spécification réutilisable, et son exemple de transmission était devenu la forme décrite.

Le format prescrit n’était pas celui que la révision retrouvait

RFC 7578 remplaça RFC 2388 en 2015 et consigna un écart rare de façon directe. La méthode imbriquée ne fut plus recommandée aux créateurs et ne fut plus exigée des récepteurs, car aucun émetteur l’implémentant n’était connu. Pour correspondre aux implémentations observées par les auteurs, chaque fichier reçut sa propre partie de premier niveau ; plusieurs parties associées au même contrôle répétaient le paramètre name.

Le regroupement changeait ainsi d’emplacement. Avant, une partie nommée contenait une liste MIME interne. Après, plusieurs parties voisines dans le flux extérieur portaient le même nom de champ. RFC 7578 n’interdit pas aux récepteurs de comprendre l’ancienne enveloppe : il recommande aux bibliothèques destinées à un usage général de la reconnaître encore. La règle d’émission évolue, tandis que la compatibilité de lecture subsiste.

« Aucun émetteur connu » décrit la documentation disponible aux auteurs de la révision ; cela ne prouve pas que personne n’a jamais produit cette forme. Le RFC ne donne ni inventaire de navigateurs, ni fréquence, ni date de bascule, ni incident. Il établit néanmoins que la description normative de 1998 fut corrigée parce que les auteurs suivants ne pouvaient identifier d’expéditeur pour cette structure.

Des valeurs répétées, pas une collision

RFC 2388 avait aussi laissé deux questions ouvertes : l’ordre du formulaire devait-il correspondre à celui des parties retournées ? Que signifiaient plusieurs parties portant un nom identique ? RFC 7578 demande aux processeurs de préserver l’ordre quand le formulaire en définit un, interdit aux intermédiaires de réordonner les résultats et interdit de fusionner les parties de même nom. Ainsi, une répétition peut exprimer plusieurs valeurs d’un champ plutôt qu’une erreur de clé.

Ce n’est pas une migration générale de MIME vers un format sans structure. Les séparateurs MIME restent là, et tous les formulaires n’ont pas un ordre naturel. La correction visait le cas précis d’un contrôle multifichier : plusieurs parties de même niveau et un nom commun qui les rattache au contrôle. La requête englobante, l’ordre voulu, les octets de chaque partie et l’interprétation de l’application réceptrice restent des étapes distinctes.

Prendre le code en compte sans le sacraliser

Dans son texte sur la primauté du code en fonctionnement, Heng Lu invite à distinguer la règle écrite du comportement réellement exécuté. RFC 2388 offre ici un cas limité et lisible : RFC 7578 n’a pas conservé une recommandation antérieure pour sa seule ancienneté. Les auteurs ont adapté la structure multifichier aux émetteurs qu’ils pouvaient documenter, tout en ménageant les récepteurs qui auraient encore rencontré l’ancien format.

Le dossier ne raconte pas qui a initié ce changement, combien de logiciels étaient concernés, ni quels coûts opérationnels ont motivé la décision. Il ne démontre pas que les implémenteurs ont toujours raison, ni qu’une norme doit entériner tout comportement logiciel. La leçon plus étroite est procédurale : spécifier un format, chercher des systèmes qui l’émettent effectivement, puis prévoir comment lire les anciennes données lorsque la révision modifie la règle.

Sources