Types MIME

Les types MIME (Extensions Multipurpose Internet Mail) sont un standard pour indiquer la nature et le format des documents, fichiers ou flux d'octets. Les navigateurs et serveurs utilisent les types MIME pour déterminer comment gérer le contenu. Par exemple, recevoir image/jpeg indique au navigateur d'afficher une image. Les types MIME décrivent la nature du contenu d’un fichier ou d’une réponse HTTP, comme text/html, application/json, image/png ou application/pdf. Ils influencent rendu navigateur, téléchargements, parsing d’API, validation d’upload, cache et sécurité. Extension et type MIME ne correspondent pas toujours, d’où l’intérêt de les vérifier lors d’un diagnostic serveur, fichier inconnu ou problème d’envoi. Pour la sécurité, il ne faut pas leur faire confiance aveuglément; inspection du contenu, règles d’extension et liste autorisée doivent être combinées.

Les types MIME (Multipurpose Internet Mail Extensions) sont des identifiants normalisés pour les formats de données, définis à l'origine dans RFC 2045/RFC 2046 pour les pièces jointes des courriels, puis adoptés par HTTP (RFC 7231 §3.1.1.5) pour la négociation de contenu web. Un type MIME est structuré sous la forme type/sous-type — le type déclare la catégorie générale (text, image, audio, video, application, multipart, font, model) et le sous-type spécifie le format exact (par ex. text/html, image/png, application/json). Des paramètres optionnels suivent un point-virgule (text/html; charset=utf-8). L'Internet Assigned Numbers Authority (IANA) maintient le registre officiel des types MIME sur iana.org/assignments/media-types. L'enregistrement suit RFC 6838, qui définit un processus de révision nécessitant un document de spécification, des considérations de sécurité et des notes d'interopérabilité. Les types non enregistrés peuvent utiliser le préfixe x- (par ex. application/x-tar) comme convention pour les formats expérimentaux ou propriétaires, bien que RFC 6648 recommande d'éviter le préfixe x- au profit d'un enregistrement correct. Dans HTTP, l'en-tête Content-Type indique au client comment interpréter le corps de la réponse. Un serveur renvoyant Content-Type: image/svg+xml déclenche le moteur de rendu SVG du navigateur ; Content-Type: application/octet-stream déclenche une invite de téléchargement car le navigateur ne peut pas déterminer le format. Le navigateur utilise également les informations de type MIME pour le reniflage MIME (MIME sniffing) — lorsque le serveur omet Content-Type ou envoie un type générique, le navigateur peut inspecter les premiers octets de la réponse (octets magiques) pour deviner le format réel. Ce comportement est contrôlé par l'en-tête X-Content-Type-Options: nosniff, qui désactive le reniflage et exige que le serveur déclare le type correct. Pour les téléchargements de fichiers, l'en-tête Accept indique au serveur quels types MIME le client attend en réponse, tandis que l'attribut accept de l'élément input restreint le sélecteur de fichier à des types spécifiques (par ex. accept="image/png, image/jpeg"). Côté serveur, les fichiers téléchargés doivent être validés à la fois par leur type MIME déclaré et par leur signature de fichier (octets magiques), car aucun des deux n'est fiable à lui seul — un fichier nommé image.png avec Content-Type: image/png pourrait contenir du code exécutable. L'outil sert de référence pour rechercher le type MIME canonique d'une extension de fichier donnée, couvrant plus de 100 formats courants répartis en huit catégories.

• Structure RFC 2046 : type/sous-type — le type indique la catégorie générale de contenu et le sous-type le format exact ; des paramètres optionnels suivent un point-virgule (text/html; charset=utf-8) et sont insensibles à la casse selon la spécification, bien que la convention soit d'utiliser des minuscules.
• Enregistrement IANA (RFC 6838) : les nouveaux types de média nécessitent un document de spécification, une section de considérations de sécurité et des notes d'interopérabilité — le processus de révision garantit que les types sont bien documentés et que les conflits sont évités avant leur entrée dans le registre.
• En-tête HTTP Content-Type : le serveur déclare le type MIME du corps de la réponse ; les navigateurs l'utilisent pour sélectionner le moteur de rendu approprié (analyseur HTML, décodeur d'image, visionneuse PDF) ou déclencher un téléchargement — un Content-Type incorrect est la cause la plus fréquente des bugs de « téléchargement au lieu de l'affichage ».
• Reniflage MIME et X-Content-Type-Options : lorsque Content-Type est absent ou générique, les navigateurs peuvent inspecter les octets magiques pour deviner le format — X-Content-Type-Options: nosniff désactive ce comportement et exige une correspondance exacte du Content-Type, ce qui constitue une bonne pratique de sécurité.
• application/octet-stream : le type de repli binaire générique — les navigateurs le traitent comme un flux opaque et déclenchent un téléchargement, ce qui en fait la valeur par défaut la plus sûre lorsque le serveur ne peut pas déterminer le format, mais cela empêche l'aperçu dans le navigateur de contenu autrement affichable.
• Validation des téléchargements de fichiers : l'attribut accept du filtre input côté client, mais la validation côté serveur doit vérifier à la fois le Content-Type déclaré et les octets magiques du fichier — une incohérence entre l'extension, le type MIME et la signature du fichier est un signal d'alarme pour les téléchargements malveillants.
• Types propriétaires et expérimentaux : la convention du préfixe x- (application/x-tar, video/x-matroska) précède le processus d'enregistrement formel — RFC 6648 recommande de migrer ces types vers des types IANA correctement enregistrés lorsque c'est possible, mais beaucoup restent largement utilisés.