Aussi disponible en : English · Español · Português · العربية
Types MIME
Les types de médias qu’on peut réellement vous servir, les enregistrés signalés et les divergences tranchées.
Qu’est-ce qu’un type MIME ?
Un type MIME — la norme dit désormais type de média — est l’étiquette qu’un serveur colle à un fichier pour que le navigateur sache de quoi il s’agit. Il voyage dans l’en-tête Content-Type, ressemble à text/html ou image/png, et c’est lui qui décide si votre navigateur affiche une page, montre une image ou vous propose un téléchargement. S’il est faux, un fichier parfaitement sain arrive en charabia ou en téléchargement inattendu.
La liste qui fait foi est le registre des types de médias de l’IANA, qui en compte 2 318 répartis en neuf arbres de premier niveau. Cette page est construite à partir de ce registre, du mime.types d’Apache httpd et de celui de nginx, tous trois téléchargés et non remémorés.
Et elle n’est délibérément pas un déversement du registre, pour une raison qu’il vaut mieux connaître avant d’aller le consulter soi-même.
Comment utiliser cette liste
- Cherchez par extension ou par type. Une extension correspond exactement, avec ou sans le point : webp et .webp fonctionnent pareil. Tout le reste est cherché dans le type : image/ vous donne l’arbre des images et +xml les types à suffixe structuré.
- Regardez l’étiquette avant de vous fier à un type. Enregistré signifie qu’il figure au registre de l’IANA, et la référence à côté est le RFC ou l’organisation qui l’y a inscrit. Les autres sont des types qu’un serveur web vous enverra sans sourciller et qu’aucun registre n’a jamais vus.
- Lisez la table des divergences si votre fichier est de ceux qui posent problème. Treize extensions reçoivent des réponses différentes d’Apache et de nginx, et la table indique à qui le registre donne raison dans chaque cas.
Le registre ne peut pas répondre à la question qui vous amène
Presque tout le monde arrive sur une liste de types MIME avec la même question : quel Content-Type envoyer pour un fichier .webp ? Le registre de l’IANA ne peut pas vous le dire. Ses colonnes sont Nom, Modèle et Référence : il n’y a aucune colonne d’extensions, parce que quelle extension correspond à quel type n’est pas ce que l’IANA enregistre. Vous pouvez chercher image/webp et confirmer son existence ; vous ne pouvez pas chercher .webp.
Rien d’autre ne comble le vide. La norme MIME Sniffing du WHATWG, celle que les navigateurs implémentent réellement, énonce sans détour que les extensions ne servent pas à déterminer le type d’une ressource obtenue par HTTP car elles ne sont pas fiables et se falsifient aisément, et elle ne publie aucune table d’extensions. La correspondance n’est tout simplement normalisée nulle part.
Ce qui tranche en pratique, c’est le serveur web placé devant vos fichiers. Cette liste applique donc une règle annoncée plutôt qu’une sélection à la main : elle contient tout type de média auquel Apache httpd ou nginx associe au moins une extension, soit 790, c’est-à-dire l’ensemble qu’on peut réellement vous servir. Le total du registre est imprimé à côté pour que nul ne prenne la partie pour le tout.
Deux serveurs, 91 extensions communes, 13 divergences
Apache associe 998 extensions et nginx 110. Quatre-vingt-onze figurent chez les deux, et sur treize d’entre elles — 14,3 % — chacun donne une réponse différente. Ce ne sont pas des formats obscurs : on y trouve .js et .xml, deux des types de fichiers les plus servis du web.
Un simple décompte de divergences ne vaudrait rien, aussi chaque conflit est-il tranché ici à l’aide du registre. Trois reviennent nettement à Apache : pour .bmp, .m4a et .pdb, Apache donne un type enregistré et nginx un type qui ne l’est pas. Six sont nginx se rabattant sur application/octet-stream, qui est enregistré, techniquement correct et ne dit rien au navigateur — c’est ce qui fait que .exe, .iso et .deb se téléchargent au lieu de mal tourner. Deux n’ont de type enregistré d’aucun côté.
Les deux derniers sont les intéressants, et ils le sont en sens inverse. Pour .xml, application/xml et text/xml sont tous deux enregistrés, et le RFC 7303 les enregistre à dessein tous les deux : aucun serveur n’a tort et il n’y a pas de réponse à trouver. Pour .js, les deux sont enregistrés aussi, mais l’entrée d’application/javascript cite le RFC 9239, le document qui a fait de text/javascript la forme standard et rendu les autres obsolètes. Apache est à jour ; nginx est en retard. Même symptôme en surface, explication radicalement différente, et seule la lecture des références permet de les distinguer.
Un tiers de ce qu’on peut vous servir n’est pas au registre
Sur les 790 types de médias que ces serveurs associent à des extensions, 547 figurent au registre de l’IANA et 243 non. Cela représente près d’un tiers de tout ce qu’une installation par défaut remet à un navigateur, avec un Content-Type qu’aucun organisme de normalisation n’a jamais consigné. La plupart sont les restes préfixés x- de formats jamais enregistrés, et ils fonctionnent très bien en pratique précisément parce que personne ne vérifie.
Sept vont plus loin encore et emploient un arbre de premier niveau qui n’existe pas. L’IANA en enregistre neuf — application, audio, font, image, message, model, multipart, text et video — et Apache livre six types chemical/* pour des formats de fichiers moléculaires, plus un sous x-conference. Un serveur web fraîchement installé vous servira un Content-Type dont le premier composant n’est même pas un arbre enregistré.
Rien de scandaleux là-dedans : c’est ainsi que finit par fonctionner une convention trentenaire sans mécanisme de contrôle. Mais mieux vaut le savoir avant de tenir pour standard un type croisé dans un fichier de configuration.
Limites honnêtes
Ceci est un instantané de trois documents mouvants, et la date de construction est imprimée en bas. Le registre gagne des entrées régulièrement et les deux serveurs mettent à jour leurs correspondances ; le script qui assemble le tout se trouve dans le dépôt, la page peut donc dire quand elle était exacte.
Deux serveurs ne sont pas non plus tous les serveurs. IIS, Caddy, les frameworks Node, les CDN et la bibliothèque standard de chaque langage portent leur propre table, et ne s’accorderont pas davantage avec ces deux-là dans tous les cas. Apache et nginx ont été retenus parce qu’ils servent l’essentiel du web, non parce qu’ils seraient les seuls avis existants.
Et la limite de fond est celle que rappelle la norme de sniffing : le type déclaré par un serveur ne prouve rien du contenu d’un fichier. N’importe qui peut téléverser un fichier nommé photo.png rempli de HTML, ce qui est précisément pourquoi les navigateurs reniflent le contenu et pourquoi il ne faut jamais fonder une décision de sécurité sur un en-tête Content-Type.
Pourquoi est-ce gratuit ?
Parce que c’est une liste de faits publics assemblée à partir de trois sources publiques. La page est du texte statique avec un champ de recherche qui la filtre dans votre navigateur : rien n’est envoyé, rien n’est conservé, et aucun serveur n’intervient pour la lire.
Il n’y a donc ni compte, ni inscription, ni rien de réservé. Le registre est un document public, les deux fichiers mime.types sont libres, et le script qui en tire cette page est dans le dépôt à côté d’elle.