A CDN removed GZIP producing mojibake in filenames and character set header enforcement fixing corrupted downloads – WP Reset

When large-scale websites rely on global infrastructure to deliver content reliably and efficiently, Content Delivery Networks (CDNs) play a crucial role. In addition to simply caching assets closer to users, CDNs also help compress files, speed up downloads, and improve the user experience. However, under certain circumstances they can unintentionally introduce new problems. One such incident involved mishandling GZIP compression and character sets, leading to corrupt downloads and mojibake (garbled text) in filenames – a phenomenon that challenged developers and operators alike.

TL;DR: A misconfiguration in a CDN service led to GZIP compression headers being removed from downloadable files and the character encoding of file names being misunderstood. This resulted in downloads with corrupted or unreadable file names (mojibake). The problem was eventually resolved by forcing the correction charset in HTTP headers, ensuring that both the file name encoding and the content were interpreted correctly by the browser. This case highlights the importance of consistency when encoding content, especially when using CDNs that can change HTTP headers.

What went wrong: Mismanagement of compression

The core of the problem was the CDN’s inappropriate handling of the Content-Encoding header. The origin server correctly compressed the files using GZIP and tagged them with the following header:

Content-Encoding: gzip

However, the CDN – intended to optimize delivery – decided to remove this header and display the content as if it were uncompressed. This worked fine for browsers that expected raw files like CSS or JavaScript, but when users tried to download files like CSVs, PDFs, or ZIP archives, they received corrupted downloads. Unpacking such files failed outright or returned data that appeared unreadable or incomplete.

In addition to binary corruption, an even more mysterious problem emerged: some file names appeared distorted with strange symbols, especially when downloaded using browsers like Chrome or Firefox. This phenomenon is known as mojibakeand it occurs when a program interprets a sequence of bytes using an unintended character encoding.

Confusion in character encodings

Mojibake in downloaded filenames usually occurs when:

• The file name contains non-ASCII characters (such as accented letters or Asian scripts)
• The browser does not know which character set to use
• The Content-Disposition or Content-Type headers lack proper character set declarations

The browser misguesses and tries to interpret the file name using a standard or fallback encoding such as ISO-8859-1, resulting in gibberish instead of readable characters. This usually affects users who download files with filenames in languages ​​such as Japanese, Russian or German, where special characters appear.

Originally, the developers set the appropriate application server headers, such as:

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

But again, the CDN modified these headers by removing or replacing them, leading to downloads without the character hint. This caused incorrect browser behavior because the filename was interpreted with the wrong encoding.

The solution: enforce character set in HTTP headers

After much debugging and log tracing, the developers confirmed the following:

• The files are not corrupted on the original server.
• Downloads were successful via curl and direct IP access.
• The problem only occurred when playing via the CDN.

Therefore, the right solution was twofold:

1. Force the CDN to keep Content-Encoding headers so that browsers properly receive and decompress GZIP content.
2. Set explicitly charset on both Content-Type and inside Content-Disposition headers to ensure correct decoding of international filenames.

The final working header configuration looked like this:

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

The use of filename* of UTF-8'' The URL encoding syntax ensures that browsers interpret the file name according to RFC 5987. This is particularly supported in modern browsers, tuning cross-platform behavior.

Why CDNs change headers

CDNs often focus on optimizing performance, reducing redundancy, and standardizing responses. To this end they can:

• Strip or replace compression guidelines
• Normalize content types
• Remove headers that do not pass security filters or caching rules

However, these optimizations can backfire if they override carefully set parameters that are crucial for displaying content or downloading files. In this incident, the CDN failed to maintain the correct Content-Encoding And charset proved detrimental to both usability and internationalization.

Lessons learned

This issue serves as a valuable reminder for developers working in distributed environments:

• Always test content delivery end-to-end. Files running on your server may behave differently behind a CDN.
• Be explicit in headers. Don’t assume standard behavior; always indicate the content type, encoding and character set.
• Control CDN behavior through configuration. Most CDNs allow overrides or rules to preserve headers. Use them.
• Monitor download behavior across browsers and locales. Internationalization bugs often only appear under these conditions.

Frequently asked questions

What is mojibake?

Mojibake is a term used to describe the unreadable or incorrect display of characters caused by character encoding mismatches. It often occurs when software misinterprets the character encoding used to store or transmit text data.

How does gzip affect file downloads?

When used correctly, GZIP compresses files to reduce download time. However, if a file is presented as GZIP compressed, the correct functionality is missing Content-Encoding: gzip header, browsers may fail to decompress it, leading to corrupted or unreadable downloads.

Why would a CDN remove headers such as Content-Encoding or charset?

CDNs prioritize performance and security. In doing so, they often normalize headers or apply policies that remove potentially unsafe or unnecessary information. This may accidentally delete critical metadata necessary for proper processing of the content.

What is the correct way to specify non-ASCII filenames for downloads?

Use the Content-Disposition cup with the filename* attribute using UTF-8 encoding and percentage-escaped format, as specified in RFC 5987. For example:

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

How can developers avoid such problems in the future?

They should run tests through the CDN layer, specify headers explicitly, and use CDN configurations that retain or pass all required metadata. Additionally, maintaining documentation of how CDNs change traffic is essential during the debugging phases.