Résumé

  • RFC 1806 a ajouté à MIME les dispositions inline et attachment, avec un nom de fichier facultatif, mais ces valeurs exprimaient une préférence et non la preuve d’un affichage ou d’un enregistrement.
  • Le traitement prudent des dispositions inconnues comme pièces jointes plaçait le risque d’exposition automatique du côté du récepteur, qui connaissait ses capacités et sa politique.
  • Les révisions ultérieures ont enrichi les dates, les noms internationaux, les téléchargements HTTP et les formulaires sans jamais autoriser l’émetteur à choisir un chemin local ou à déclencher une exécution.

Un message savait transporter sans savoir présenter

Avec RFC 1521, un courrier Internet pouvait devenir un assemblage de textes, d’images, d’applications et de conteneurs multiparties. RFC 2045 et RFC 2046 ont ensuite consolidé cette grammaire. Le destinataire pouvait reconnaître le type déclaré d’une partie et retrouver ses octets après décodage.

Mais connaître le matériau ne disait pas comment l’introduire dans l’interface. Une image pouvait apparaître au fil du texte, derrière une icône ou dans une liste. Un terminal et un poste graphique n’avaient ni les mêmes capacités ni les mêmes dangers. MIME décrivait le contenu ; il manquait un moyen de communiquer la préférence de présentation de l’auteur.

Publiée à titre expérimental en juin 1995, RFC 1806 a installé ce moyen sous la forme d’un champ Content-Disposition facultatif applicable à une entité MIME. Son absence laissait explicitement l’agent utilisateur libre de choisir la présentation convenable. Le nouveau champ n’a donc pas retiré un pouvoir au destinataire. Il a ajouté une information que celui-ci pouvait confronter à son contexte local.

La valeur inconnue ne recevait pas un privilège

Le vocabulaire initial ne comptait que deux dispositions. inline signalait qu’une partie devait normalement être présentée dans le flux du message, sous réserve des règles de son conteneur. attachment demandait qu’une action supplémentaire de l’utilisateur précède sa présentation. L’interface exacte — icône, menu, liste ou autre — restait locale.

Le cas le plus révélateur n’était pourtant pas l’un de ces deux mots, mais le troisième mot encore inconnu. RFC 1806 prescrivait qu’un type de disposition non reconnu soit traité comme attachment. Une extension future ne gagnait donc pas, par simple nouveauté, un droit à l’affichage automatique. Les paramètres inconnus pouvaient être ignorés ; leur présence ne transformait pas le logiciel en interprète d’une sémantique inventée.

Ce repli prudent n’était pas un jugement sur les octets. Il limitait seulement l’automaticité. Une pièce jointe pouvait encore être ouverte par la personne et un élément inline pouvait être refusé par une politique de sécurité ou faute de décodeur. Le champ exprimait le prochain geste souhaité ; il n’attestait ni le rendu, ni la lecture, ni la sauvegarde.

Les conteneurs imbriqués rendaient cette séparation observable. Une disposition attachée à une entité multipartie portait sur le conteneur entier. Si celui-ci était une pièce jointe, il fallait d’abord franchir ce seuil ; les dispositions des parties internes ne devenaient pertinentes qu’après l’ouverture. Une seule enveloppe pouvait ainsi comporter plusieurs décisions successives, sans qu’un label externe prouve que la partie la plus profonde avait jamais été atteinte.

Le nom voyageait, le chemin ne devait pas suivre

Le paramètre facultatif filename proposait un nom pour l’archivage si le destinataire décidait d’extraire la partie. Il pouvait aussi accompagner un élément inline, auquel cas aucun fichier n’était nécessairement créé. La présence du nom n’était pas une demande d’écriture et encore moins le reçu d’une écriture.

RFC 1806 demandait de ne pas respecter les informations de répertoire contenues dans cette valeur. Le logiciel devait isoler le dernier composant utile, adapter le nom aux conventions du système et empêcher l’écrasement d’un fichier existant. La raison est structurelle : l’émetteur ignore les séparateurs locaux, les noms réservés, les répertoires autorisés, les collisions et les applications associées aux extensions.

La section de sécurité énumérait des conséquences très concrètes : créer un fichier de démarrage, remplacer un fichier système, écraser un document existant, déposer un exécutable dans un chemin de commandes ou envoyer le contenu vers un tube. Le récepteur devait empêcher que le choix du nom ou de l’emplacement provoque une interprétation ou une exécution sans initiative explicite de l’utilisateur.

Il faut donc distinguer cinq faits. Un émetteur a produit une chaîne. Un parseur l’a reconnue comme paramètre. Une politique l’a nettoyée. Une opération locale a choisi un chemin réel. Une application a peut-être ensuite interprété les octets. Le champ reçu peut documenter les deux premiers faits ; il ne suffit pas à établir les trois autres.

La normalisation a ajouté des attributs, pas de l’autorité

La notice de RFC 1806 indique que l’expérience a été remplacée en août 1997 par RFC 2183, publiée sur la voie des standards. Le texte révisé conservait les deux dispositions et les précautions sur le nom local. Il ajoutait des dates de création, de modification et de lecture ainsi qu’une taille approximative.

Ces paramètres donnaient l’apparence d’une fiche de fichier plus complète, mais demeuraient des assertions transportées. RFC 2183 avertissait notamment que le champ Unix ou POSIX st_ctime ne représente pas une date de création. Le destinataire pouvait choisir de préserver une date ; il ne recevait pas pour autant une chronologie authentifiée. La taille pouvait aider à estimer l’espace nécessaire, sans prouver que l’écriture était complète ou même possible.

La révision organisait aussi l’enregistrement des extensions auprès de l’IANA. Le registre Content Disposition actuel rassemble les valeurs initiales et celles définies ensuite pour des contextes particuliers. Un enregistrement stabilise un nom et sa référence. Il ne prouve pas que tous les clients le comprennent, ni qu’une valeur enregistrée convient à chaque emplacement protocolaire.

Donner un nom humain exigeait une seconde grammaire

La syntaxe de départ limitait le nom proposé à l’US-ASCII. Pour un attribut destiné à être lu par une personne, cette frontière excluait une grande partie des écritures ordinaires. RFC 2231 a apporté des continuations pour les valeurs longues ainsi qu’une notation comprenant jeu de caractères, langue facultative et octets encodés en pourcentage.

Cette solution créait un travail de reconstruction qu’il fallait pouvoir auditer. Les segments numérotés peuvent manquer, arriver dans un ordre inattendu ou mélanger formes étendue et simple. Le jeu de caractères peut être inconnu. La langue renseigne la présentation, elle ne modifie pas les octets. Une chaîne Unicode affichée est donc le résultat d’un choix de segments et d’un décodage, pas la copie brute du message.

Une représentation fidèle ne rend pas le nom sûr. Une traversée de répertoire bien décodée reste une traversée. Un nom de périphérique parfaitement accentué peut rester réservé. RFC 2231 améliorait l’expression d’un nom humain ; elle ne déplaçait pas la frontière d’autorisation du système local.

Le Web a repris le contrat avant de le formaliser

En 1999, RFC 2616 constatait que Content-Disposition était souvent mis en œuvre dans HTTP bien qu’il ne fasse pas alors partie de la norme HTTP. Les serveurs Web avaient retrouvé le besoin des expéditeurs de courrier : demander un téléchargement distinct et proposer un nom utile.

RFC 6266 a normalisé cet usage dans les réponses HTTP en 2011. Elle qualifie le nom de fichier d’indication seulement. L’agent utilisateur doit retirer tous les composants de chemin sauf le dernier, se méfier d’une extension qui déclencherait un traitement dangereux, neutraliser les caractères de contrôle et les noms spéciaux, et empêcher le serveur de choisir un emplacement non autorisé.

Lorsqu’une réponse contient à la fois filename et la forme étendue filename*, un destinataire qui comprend les deux doit préférer la seconde. RFC 8187 a ensuite resserré l’encodage des paramètres HTTP et imposé la prise en charge d’UTF-8. Cette préférence aussi mérite une trace : valeurs brutes, paramètre choisi, décodeur et nom affiché ne sont pas un seul fait.

Dans un formulaire, le même champ changeait de direction

Le champ apparaît aussi à l’intérieur de corps multipart/form-data, mais RFC 6266 exclut expressément ces parties de son profil de réponse HTTP. RFC 7578 exige pour chaque partie la disposition form-data et le paramètre name; une partie fichier devrait aussi porter filename lorsqu’un nom utile existe.

Ici, le navigateur est l’émetteur et l’application Web devient le récepteur qui doit protéger son stockage. RFC 7578 répète qu’il ne faut pas utiliser aveuglément le nom fourni et qu’il faut supprimer les informations de chemin. Elle interdit en outre filename* dans ce contexte, alors que les réponses HTTP l’emploient. Partager un nom de champ ne suffit pas à partager sa grammaire.

L’héritage de RFC 1806 n’est donc pas seulement l’icône du trombone. C’est un contrat de pouvoir étroit : une partie distante peut décrire une présentation souhaitée et proposer un nom intelligible. La partie locale décide toujours si les octets deviennent visibles, s’ils deviennent un fichier, sous quel nom effectif et à la suite de quelle action.

Sources