Un CDN a supprimé GZIP et a produit du mojibake dans les noms de fichiers et l'application de l'en-tête du jeu de caractères qui a corrigé les téléchargements corrompus.

Publié: 2025-11-21

Lorsque les sites Web à grande échelle s'appuient sur une infrastructure mondiale pour fournir du contenu de manière fiable et efficace, les réseaux de diffusion de contenu (CDN) jouent un rôle essentiel. Au-delà de la simple mise en cache des actifs plus proches des utilisateurs, les CDN aident également à compresser les fichiers, à accélérer les téléchargements et à améliorer l'expérience utilisateur. Cependant, dans certaines conditions, ils peuvent introduire par inadvertance de nouveaux problèmes. L’un de ces incidents impliquait une mauvaise gestion de la compression GZIP et des jeux de caractères, entraînant des téléchargements corrompus et du mojibake (texte tronqué) dans les noms de fichiers – un phénomène qui a mis au défi les développeurs et les opérateurs.

TL;DR : une mauvaise configuration dans un service CDN l'a conduit à supprimer les en-têtes de compression GZIP des fichiers téléchargeables et à une mauvaise compréhension du codage des caractères des noms de fichiers. Cela entraînait des téléchargements avec des noms de fichiers corrompus ou illisibles (mojibake). Le problème a finalement été résolu en forçant le charset correct dans les en-têtes HTTP, garantissant ainsi que l'encodage du nom de fichier et le contenu étaient interprétés correctement par le navigateur. Ce cas met en évidence l’importance de la cohérence dans l’encodage du contenu, en particulier lors de l’utilisation de CDN susceptibles de modifier les en-têtes HTTP.

Ce qui n'a pas fonctionné : une mauvaise gestion de la compression

Au cœur du problème se trouvait la gestion inappropriée par le CDN de l’en-tête Content-Encoding . Le serveur d'origine a correctement compressé les fichiers à l'aide de GZIP et les a étiquetés avec l'en-tête suivant :

 Content-Encoding: gzip

Cependant, le CDN – destiné à optimiser la livraison – a décidé de supprimer cet en-tête et de diffuser le contenu comme s'il n'était pas compressé. Cela fonctionnait bien pour les navigateurs qui attendaient des fichiers bruts comme CSS ou JavaScript, mais lorsque les utilisateurs essayaient de télécharger des fichiers tels que des fichiers CSV, PDF ou des archives ZIP, ils recevaient des téléchargements corrompus. La décompression de ces fichiers a échoué ou a produit des données qui semblaient illisibles ou incomplètes.

Au-delà de la corruption binaire, un problème encore plus mystérieux est apparu : certains noms de fichiers apparaissaient déformés avec des symboles étranges, notamment lorsqu'ils étaient téléchargés à l'aide de navigateurs comme Chrome ou Firefox. Ce phénomène est connu sous le nom de mojibake et se produit lorsqu'un programme interprète une séquence d'octets en utilisant un codage de caractères involontaire.

Confusion dans les encodages de caractères

Mojibake dans les noms de fichiers téléchargés se produit généralement lorsque :

Le nom du fichier contient des caractères non-ASCII (tels que des lettres accentuées ou des écritures asiatiques)
Le navigateur ne sait pas quel jeu de caractères utiliser
Les en-têtes Content-Disposition ou Content-Type ne disposent pas de déclarations de jeu de caractères appropriées.

Le navigateur, se trompant, essaie d'interpréter le nom de fichier en utilisant un codage par défaut ou de secours comme ISO-8859-1, ce qui conduit à du charabia à la place de caractères lisibles. Cela affecte généralement les utilisateurs qui téléchargent des fichiers dont les noms sont rédigés dans des langues comme le japonais, le russe ou l'allemand, où les caractères spéciaux sont répandus.

À l'origine, les développeurs avaient défini des en-têtes appropriés à partir du serveur d'applications, tels que :

 Content-Type: application/octet-stream; charset=utf-8 Content-Disposition: attachment; filename="resume.pdf"

Mais, encore une fois, le CDN a modifié ces en-têtes en les supprimant ou en les remplaçant, conduisant à des téléchargements sans l'indication du jeu de caractères. Cela a déclenché un comportement incorrect du navigateur car le nom de fichier a été interprété avec un mauvais codage.

Le correctif : appliquer le jeu de caractères dans les en-têtes HTTP

Après de nombreux débogages et suivi des journaux, les développeurs ont confirmé que :

Les fichiers n'ont pas été corrompus sur le serveur d'origine.
Les téléchargements ont réussi via curl et un accès IP direct.
Le problème ne s'est produit que lors de la diffusion via le CDN.

La bonne solution était donc double :

Forcez le CDN à conserver les en-têtes Content-Encoding afin que les navigateurs reçoivent et décompressent correctement le contenu GZIP.
Définissez charset explicite sur les en-têtes Content-Type et Content-Disposition pour garantir un décodage correct des noms de fichiers internationaux.

La configuration finale de l'en-tête de travail ressemblait à ceci :

 Content-Type: application/octet-stream; charset=utf-8 Content-Disposition: attachment; filename*=UTF-8''r%C3%A9sum%C3%A9.pdf Content-Encoding: gzip

L'utilisation du filename* avec la syntaxe de codage d'URL UTF-8'' garantit que les navigateurs interprètent le nom de fichier conformément à la RFC 5987. Ceci est particulièrement pris en charge dans les navigateurs modernes, alignant le comportement multiplateforme.

Pourquoi les CDN modifient les en-têtes

Les CDN visent souvent à optimiser les performances, à réduire la redondance et à standardiser les réponses. A cette fin, ils peuvent :

Supprimer ou remplacer les directives de compression
Normaliser les types de contenu
Supprimez les en-têtes qui ne passent pas les filtres de sécurité ou les règles de mise en cache

Cependant, ces optimisations peuvent se retourner contre elles lorsqu’elles remplacent des paramètres soigneusement définis, essentiels au rendu du contenu ou au téléchargement de fichiers. Dans cet incident, l'incapacité du CDN à préserver le Content-Encoding et charset corrects s'est avérée préjudiciable à la fois à la convivialité et à l'internationalisation.

Leçons apprises

Ce problème constitue un rappel précieux pour les développeurs travaillant dans des environnements distribués :

Testez toujours la diffusion de contenu de bout en bout. Les fichiers qui fonctionnent sur votre serveur peuvent se comporter différemment derrière un CDN.
Soyez explicite dans les en-têtes. Ne présumez rien des comportements par défaut : déclarez toujours le type de contenu, l'encodage et le jeu de caractères.
Contrôlez le comportement du CDN via la configuration. La plupart des CDN autorisent les remplacements ou les règles pour conserver les en-têtes. Utilisez-les.
Vérifiez le comportement de téléchargement dans plusieurs navigateurs et paramètres régionaux. Les bugs d’internationalisation n’apparaissent souvent que dans ces conditions.

FAQ

Qu’est-ce que le mojibake ?

Mojibake est un terme utilisé pour décrire l'affichage tronqué ou incorrect des caractères provoqué par des discordances d'encodage de caractères. Cela se produit souvent lorsque le logiciel interprète mal le codage des caractères utilisé pour stocker ou envoyer des données texte.

Comment gzip affecte-t-il les téléchargements de fichiers ?

Lorsqu'il est utilisé correctement, GZIP compresse les fichiers pour réduire le temps de téléchargement. Cependant, si un fichier est compressé au format GZIP alors qu'il lui manque l'en-tête Content-Encoding: gzip approprié, les navigateurs peuvent ne pas le décompresser, ce qui entraîne des téléchargements corrompus ou illisibles.

Pourquoi un CDN supprimerait-il les en-têtes comme Content-Encoding ou charset ?

Les CDN donnent la priorité aux performances et à la sécurité. Ce faisant, ils normalisent souvent les en-têtes ou appliquent des politiques qui suppriment les informations potentiellement dangereuses ou inutiles. Cela peut supprimer par inadvertance les métadonnées critiques nécessaires à la gestion correcte du contenu.

Quelle est la manière correcte de spécifier des noms de fichiers non-ASCII pour les téléchargements ?

Utilisez l'en-tête Content-Disposition avec l'attribut filename* en utilisant le codage UTF-8 et le format d'échappement en pourcentage, comme spécifié dans la RFC 5987. Par exemple :

Content-Disposition: attachment; filename*=UTF-8''r%C3%A9sum%C3%A9.pdf

Comment les développeurs peuvent-ils éviter de tels problèmes à l’avenir ?

Ils doivent effectuer des tests via la couche CDN, spécifier explicitement les en-têtes et utiliser des configurations CDN qui préservent ou transmettent toutes les métadonnées requises. De plus, il est essentiel de conserver une documentation sur la façon dont les CDN modifient le trafic pendant les phases de débogage.