Aussi disponible en : English · Español · Português · العربية
Générateur et vérificateur d’en-tête Content-Disposition
Écrivez un en-tête qui nomme correctement un téléchargement dans tous les navigateurs, ou collez-en un et découvrez sous quel nom le fichier sera enregistré.
À quoi sert l’en-tête Content-Disposition
Content-Disposition est l’en-tête de réponse qui transforme une page en téléchargement et donne un nom au fichier enregistré. Il comporte une partie obligatoire, le type de disposition, et les paramètres qui comptent ici sont filename et filename*. Le type attachment demande au navigateur de proposer un enregistrement ; inline lui demande de se comporter normalement, et c’est pourquoi inline ne sert à quelque chose qu’accompagné d’un nom — sinon il réclame exactement ce qui se passe sans aucun en-tête.
Un troisième cas mérite d’être connu parce qu’il passe inaperçu : la RFC 6266 indique qu’un type de disposition inconnu ou non pris en charge doit être traité comme attachment. Une coquille comme attachement n’aboutit donc pas à un affichage, mais à un téléchargement. Cet outil le signale plutôt que de laisser passer, car un en-tête qui fonctionne par accident est un en-tête que personne ne relit.
Le nom de fichier est indicatif au sens le plus fort. La spécification demande aux destinataires la plus grande prudence : ne jamais se fier à l’information de dossier, ne conserver que le dernier segment du chemin, n’écrire nulle part sans autorisation de l’utilisateur, et supprimer ou remplacer les caractères de contrôle ainsi que les espaces de début et de fin. Si un navigateur a renommé votre fichier, il appliquait la règle.
Comment s’en servir
- Choisissez un mode. Composer un en-tête prend le nom que doit voir le visiteur et écrit l’en-tête correspondant. Vérifier un en-tête prend celui dont vous disposez déjà — collé avec ou sans le nom du champ — et en déduit ce qu’un destinataire en fait.
- En mode composition, tapez le nom tel quel. Accents compris. Choisissez attachment ou inline, puis l’orthographe du repli ASCII pour une lettre accentuée : la graphie des passeports transforme ä en ae, ou vous pouvez vous en tenir à un simple a. Le bouton copie l’en-tête.
- En mode vérification, lisez les deux lignes qui comptent. Nom retenu est celui qu’un navigateur actuel enregistre réellement, et Provient de indique lequel des deux paramètres l’a fourni. Les constats se répartissent en erreurs, qui cassent quelque chose ; avertissements, valides mais qui jouent contre vous ; et remarques, valides et sans le moindre effet.
Pourquoi un en-tête correct envoie le nom deux fois
C’est la partie qui surprend, et c’est toute la raison d’être de l’outil. La RFC 6266 précise que les deux paramètres ne diffèrent que par l’encodage employé par filename*, lequel admet des caractères hors ISO-8859-1 — puis, et c’est décisif, que lorsque les deux figurent dans une même valeur d’en-tête, les destinataires doivent retenir filename* et ignorer filename. Le conseil n’est pas de remplacer l’un par l’autre. C’est d’envoyer les deux.
La raison tient à la compatibilité. La forme étendue est arrivée après le déploiement de quantité de logiciels : envoyer filename* seul ne laisse rien aux plus anciens, et envoyer filename seul vous enferme dans un jeu de caractères incapable d’écrire la plupart des noms du monde. L’annexe D du même document met l’ordre par écrit : inclure filename quand l’US-ASCII suffit, ajouter filename* quand il ne suffit pas, produire le repli par substitution de séquences ASCII, et placer filename en premier, car certains analyseurs existants s’arrêtent au premier nom qu’ils comprennent.
Ce conseil de substitution arrive avec son propre exemple — la lettre ä devient ae —, c’est-à-dire la graphie des passeports et non celle d’une lettre unique, et c’est celle que cet outil applique par défaut. La table qui la porte est celle qu’emploie déjà le générateur de slugs du site, tirée du Doc 9303 de l’OACI, et elle existe parce que la recette évidente est fausse : normaliser puis retirer les signes diacritiques supprime purement et simplement une douzaine de lettres latines au lieu de les replier, si bien que Ærø se réduit à la seule lettre r et que Straße perd son ß. Ici, Ærø.txt a pour repli AEroe.txt.
L’annexe D avoue aussi la limite de son propre conseil, en une clause : cela peut se révéler impossible dans certaines langues. Un nom entièrement écrit en japonais ou en arabe n’a aucune graphie ASCII, et cet outil n’en invente donc pas. Il écrit un radical de substitution, conserve l’extension, énumère chaque caractère qu’il n’a pas su écrire et le dit sur la page. Tout navigateur actuel lit filename* et obtient de toute façon le vrai nom ; seul un logiciel vraiment ancien voit le substitut.
La valeur étendue n’est pas encodeURIComponent
L’encodage de filename* est défini par la RFC 8187, et ce n’est pas l’encodage d’URL, même s’il lui ressemble assez pour tromper presque tout le monde. La valeur est un nom d’encodage de caractères, deux apostrophes, puis une suite où chaque caractère est soit encodé en pourcentage, soit tiré d’un ensemble que la spécification nomme attr-char : les caractères de token moins l’astérisque, l’apostrophe et le pourcentage.
Comparez cet ensemble à encodeURIComponent, vers quoi se tourne pratiquement tout exemple de code, et les deux divergent dans les deux sens. Balayé sur tout l’ASCII, encodeURIComponent laisse en place exactement quatre caractères qu’attr-char interdit : l’apostrophe, les deux parenthèses et l’astérisque. Il en encode par ailleurs sept qu’attr-char autorise, ce qui est sans conséquence, un échappement en pourcentage étant toujours licite. Les quatre premiers, eux, ne sont ni anodins ni exotiques : rapport (final).pdf et O'Brien.pdf sont des noms parfaitement ordinaires, et tous deux sortent d’encodeURIComponent en portant un caractère que la grammaire refuse.
Un second piège se cache au même endroit. La RFC 8187 a supprimé dans sa révision de 2017 l’obligation de prendre en charge ISO-8859-1 et impose désormais UTF-8 aux émetteurs : une valeur qui annonce un autre encodage est donc en retard sur la spécification, même là où elle fonctionne encore. Et la valeur étendue ne doit jamais être entre guillemets — le même document note qu’un analyseur assemblé à partir de briques génériques risque fort d’accepter la forme entre guillemets malgré tout, ce qui est précisément la manière dont une erreur pareille survit aux tests.
Ce que ceci ne vous dira pas
Ceci vérifie le texte que vous collez et rien d’autre. Un navigateur ne peut pas aller chercher les en-têtes de votre serveur : l’outil ignore donc si l’en-tête sous vos yeux est bien celui qui part, si le fichier derrière existe, et si son type de média correspond à l’extension. Un en-tête peut être irréprochable et décrire la mauvaise réponse.
Il ne dit rien non plus de la légalité du nom une fois arrivé sur le disque. Les noms de périphérique réservés, les caractères que Windows interdit et les limites de longueur forment un autre jeu de règles avec une autre réponse, et ce site propose un assainisseur de noms de fichier pour cette question-là. Les deux problèmes se ressemblent et n’ont rien en commun : celui-ci consiste à survivre à l’en-tête, l’autre à survivre au système de fichiers.
Une omission assumée : les continuations de paramètre, ce mécanisme de la RFC 2231 qui découpe une valeur longue entre filename*0* et filename*1*. La RFC 8187 affirme que les continuations ne sont pas nécessaires dans les en-têtes HTTP et ne les reprend pas ; un en-tête qui en use sort donc de ce que ceci analyse. Si vous en avez un, il vient d’un logiciel appliquant une convention MIME plus ancienne à un endroit qui ne l’a jamais réclamée.
Enfin, rien de tout cela ne rend un nom de fichier contraignant. La spécification est catégorique : le destinataire le traite comme un avis, peut substituer un nom qui signifie quelque chose de particulier pour le système de fichiers, et doit s’assurer que toute extension à laquelle il se fie est sûre. Ce qu’achète un en-tête correct, c’est la meilleure chance d’obtenir le nom voulu, pas la garantie de l’obtenir.
Pourquoi est-ce gratuit ?
Composer et analyser un en-tê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é votre nom de fichier.