Résumé

  • L'attribut HTML download demande au navigateur d'enregistrer une ressource et peut proposer son nom ; la réponse HTTP peut proposer le sien.
  • Une anomalie signalée à Mozilla en 2013, puis un débat au WHATWG en 2017, révèlent le rôle décisif de l'origine qui fournit le fichier.

Imaginez un employé de vestiaire qui reçoit un manteau avec trois tickets différents. Le premier vient de la page qui affiche « Télécharger ». Le deuxième, du serveur qui expédie le fichier. Le troisième est celui que le navigateur devra réellement remettre à l'utilisateur. L'employé a intérêt à regarder les poches avant d'accrocher quoi que ce soit. Ce petit désaccord de vestiaire explique une partie de l'histoire du téléchargement sur le Web.

En juin 2011, le RFC 6266 a précisé le langage du serveur : l'en-tête HTTP Content-Disposition. Avec attachment, le serveur oriente la réponse vers l'enregistrement. filename propose un nom ; filename* permet d'exprimer des caractères internationaux. Le texte traite ce nom comme un conseil. Il demande au destinataire d'écarter les morceaux de chemin capables de viser un autre répertoire, de surveiller les extensions dangereuses et de neutraliser certains caractères. Le manteau arrive avec une étiquette ; le vestiaire garde ses propres clés.

Une autre initiative est venue de la page. La chronologie technique publiée par Chromium place a[download] au jalon M14. Dans un lien HTML, l'attribut annonce que l'auteur souhaite un fichier plutôt qu'une visite de page. Sa valeur peut suggérer le nom local. Voilà de quoi fabriquer un bouton utile pour sauver une image, un tableau ou un document. Voilà aussi un nouveau prétendant au stylo qui écrit sur l'étiquette.

Le problème devient particulièrement visible quand le bouton et le fichier vivent sur deux sites différents. Un signalement Mozilla de 2013 présente un lien vers une image extérieure : Firefox ouvre l'image alors que Chrome la télécharge. La personne qui signale l'écart croit voir un défaut. Mozilla répond qu'il s'agit d'une mesure de sécurité nécessaire et clôt le ticket. Le clic paraît identique à l'écran ; la provenance des octets change la décision.

En avril 2017, une discussion WHATWG décrit l'écart avec plus de finesse. Dans le cas intersites examiné, Firefox et Safari ignoraient l'attribut ; Chrome lançait le téléchargement, mais abandonnait le nom suggéré par la page. Un éditeur du standard indique que l'algorithme de l'époque autorisait les deux comportements et invite à les rapprocher. Cette dispute tient dans quelques mots de balisage, avec une vraie conséquence : un site pourrait autrement pousser le navigateur à enregistrer le contenu d'un autre sous une étiquette de son choix. La même année, WebKit présentait l'arrivée de l'attribut dans Safari 10.1, y compris pour des fichiers Blob créés dans la page.

Le standard HTML actuel expose la répartition des rôles. download indique une intention et suggère éventuellement un nom. L'en-tête Content-Disposition peut passer devant cette suggestion. Lorsque le fichier vient d'une autre origine, le standard associe la demande de téléchargement à attachment côté serveur afin d'éviter une arrivée surprenante. Le navigateur inspecte aussi la destination locale et le nom final. Le bouton parle, le serveur répond, le vestiaire tranche.

Cette petite histoire donne une définition concrète d'une frontière du Web. Le site qui dessine le bouton sait ce qu'il souhaite offrir. Le serveur sait ce qu'il sert. Le navigateur connaît le dossier où le fichier va finir. Quand les trois sont d'accord, le clic paraît magique. Quand ils discutent, on aperçoit enfin les mains qui tenaient le ticket.