CDN usunął GZIP i wygenerował mojibake w nazwach plików oraz wymuszenie nagłówka zestawu znaków, które naprawiło uszkodzone pliki do pobrania

Opublikowany: 2025-11-21

Gdy duże witryny internetowe w celu niezawodnego i wydajnego dostarczania treści korzystają z globalnej infrastruktury, sieci dostarczania treści (CDN) odgrywają kluczową rolę. Oprócz zwykłego buforowania zasobów bliżej użytkowników, sieci CDN pomagają także w kompresowaniu plików, przyspieszaniu pobierania i poprawianiu komfortu użytkownika. Jednak w pewnych warunkach mogą przypadkowo wprowadzić nowe problemy. Jeden z takich incydentów dotyczył nieprawidłowej kompresji GZIP i zestawów znaków, co prowadziło do uszkodzonych plików do pobrania i mojibake (zniekształconego tekstu) w nazwach plików — zjawisko, które stanowiło wyzwanie zarówno dla programistów, jak i operatorów.

TL; DR: Błędna konfiguracja w usłudze CDN doprowadziła do usunięcia nagłówków kompresji GZIP z plików do pobrania i błędnego kodowania znaków w nazwach plików. Spowodowało to pobieranie plików z uszkodzonymi lub nieczytelnymi nazwami plików (mojibake). Ostatecznie problem został rozwiązany poprzez wymuszenie prawidłowego charset w nagłówkach HTTP, co zapewniło, że zarówno kodowanie nazw plików, jak i treść zostały poprawnie zinterpretowane przez przeglądarkę. Ten przypadek podkreśla znaczenie spójności w kodowaniu treści, szczególnie w przypadku korzystania z sieci CDN, które mogą modyfikować nagłówki HTTP.

Co poszło nie tak: złe zarządzanie kompresją

Sednem problemu była niewłaściwa obsługa nagłówka Content-Encoding przez CDN. Serwer Origin poprawnie skompresował pliki przy użyciu GZIP i oznaczył je następującym nagłówkiem:

 Content-Encoding: gzip

Jednak CDN — mając na celu optymalizację dostarczania — zdecydował się usunąć ten nagłówek i udostępnić treść tak, jakby była nieskompresowana. Działało to dobrze w przypadku przeglądarek oczekujących nieprzetworzonych plików, takich jak CSS lub JavaScript, ale gdy użytkownicy próbowali pobrać pliki, takie jak pliki CSV, PDF lub archiwa ZIP, otrzymywali uszkodzone pliki do pobrania. Rozpakowanie takich plików albo całkowicie się nie powiodło, albo spowodowało wygenerowanie danych, które wydawały się nieczytelne lub niekompletne.

Poza uszkodzeniem plików binarnych pojawił się jeszcze bardziej tajemniczy problem: nazwy niektórych plików były zniekształcone i zawierały dziwne symbole, szczególnie podczas pobierania za pomocą przeglądarek takich jak Chrome lub Firefox. Zjawisko to jest znane jako mojibake i występuje, gdy program interpretuje sekwencję bajtów przy użyciu niezamierzonego kodowania znaków.

Zamieszanie w kodowaniu znaków

Mojibake w nazwach pobranych plików zwykle pojawia się, gdy:

Nazwa pliku zawiera znaki inne niż ASCII (takie jak litery akcentowane lub pisma azjatyckie)
Przeglądarka nie wie, jakiego zestawu znaków użyć
W nagłówkach Content-Disposition lub Content-Type brakuje odpowiednich deklaracji zestawu znaków

Przeglądarka, zgadując błędnie, próbuje zinterpretować nazwę pliku, używając domyślnego lub zastępczego kodowania, takiego jak ISO-8859-1, co prowadzi do bełkotu zamiast czytelnych znaków. Zwykle dotyczy to użytkowników pobierających pliki z nazwami plików w językach takich jak japoński, rosyjski lub niemiecki, w których dominują znaki specjalne.

Pierwotnie programiści ustawili odpowiednie nagłówki z serwera aplikacji, takie jak:

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

Jednak po raz kolejny CDN zmienił te nagłówki, usuwając je lub zastępując, co doprowadziło do pobierania bez wskazówki dotyczącej zestawu znaków. Spowodowało to nieprawidłowe zachowanie przeglądarki, ponieważ nazwa pliku została zinterpretowana przy nieprawidłowym kodowaniu.

Poprawka: wymuszanie zestawu znaków w nagłówkach HTTP

Po wielu debugowaniach i śledzeniu dzienników programiści potwierdzili, że:

Pliki na serwerze źródłowym nie zostały uszkodzone.
Pobieranie przebiegło pomyślnie poprzez zwijanie i bezpośredni dostęp IP.
Problem wystąpił tylko wtedy, gdy był obsługiwany przez CDN.

Dlatego właściwym rozwiązaniem było dwojakie:

Wymuś CDN zachowanie nagłówków Content-Encoding , aby przeglądarki prawidłowo odbierały i dekompresowały zawartość GZIP.
Ustaw jawny charset zarówno w nagłówkach Content-Type , jak i w obrębie Content-Disposition , aby zagwarantować prawidłowe dekodowanie międzynarodowych nazw plików.

Ostateczna działająca konfiguracja nagłówka wyglądała następująco:

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

Użycie filename* ze składnią kodowania URL UTF-8'' gwarantuje, że przeglądarki interpretują nazwę pliku zgodnie z RFC 5987. Jest to szczególnie obsługiwane w nowoczesnych przeglądarkach, dostosowując zachowanie między platformami.

Dlaczego sieci CDN zmieniają nagłówki

Sieci CDN często mają na celu optymalizację wydajności, zmniejszenie redundancji i standaryzację odpowiedzi. W tym celu mogą:

Usuń lub zastąp dyrektywy dotyczące kompresji
Normalizuj typy treści
Usuń nagłówki, które nie przechodzą filtrów zabezpieczeń ani reguł buforowania

Jednak te optymalizacje mogą przynieść odwrotny skutek, jeśli zastąpią starannie ustawione parametry krytyczne dla renderowania treści lub pobierania plików. W tym incydencie niepowodzenie CDN w zachowaniu prawidłowego Content-Encoding i charset okazało się szkodliwe zarówno dla użyteczności, jak i umiędzynarodowienia.

Wyciągnięte wnioski

Ten problem stanowi cenne przypomnienie dla programistów pracujących w środowiskach rozproszonych:

Zawsze testuj dostarczanie treści od początku do końca. Pliki działające na Twoim serwerze mogą zachowywać się inaczej za siecią CDN.
Bądź wyraźny w nagłówkach. Nie zakładaj niczego na temat domyślnych zachowań – zawsze deklaruj typ zawartości, kodowanie i zestaw znaków.
Kontroluj zachowanie CDN poprzez konfigurację. Większość sieci CDN umożliwia zastąpienie lub reguły zachowania nagłówków. Wykorzystaj je.
Sprawdź zachowanie pobierania w wielu przeglądarkach i lokalizacjach. Błędy związane z internacjonalizacją często pojawiają się tylko w tych warunkach.

Często zadawane pytania

Co to jest mojibake?

Mojibake to termin używany do opisania zniekształconego lub nieprawidłowego wyświetlania znaków spowodowanego niezgodnością kodowania znaków. Często występuje, gdy oprogramowanie błędnie interpretuje kodowanie znaków używane do przechowywania lub wysyłania danych tekstowych.

Jak gzip wpływa na pobieranie plików?

Przy prawidłowym użyciu GZIP kompresuje pliki, aby skrócić czas pobierania. Jeśli jednak plik jest udostępniany jako skompresowany w formacie GZIP i nie ma odpowiedniego nagłówka Content-Encoding: gzip , przeglądarki mogą go nie zdekompresować, co może spowodować uszkodzenie lub nieczytelność plików do pobrania.

Dlaczego nagłówki CDN miałyby być usuwane, takie jak Content-Encoding lub zestaw znaków?

W sieciach CDN priorytetem jest wydajność i bezpieczeństwo. Robiąc to, często normalizują nagłówki lub stosują zasady, które usuwają potencjalnie niebezpieczne lub niepotrzebne informacje. Może to spowodować niezamierzone usunięcie krytycznych metadanych potrzebnych do prawidłowej obsługi treści.

Jaki jest prawidłowy sposób określania nazw plików do pobrania w formacie innym niż ASCII?

Użyj nagłówka Content-Disposition z atrybutem filename* , używając kodowania UTF-8 i formatu ze zmianą wartości procentową, jak określono w dokumencie RFC 5987. Na przykład:

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

Jak programiści mogą uniknąć takich problemów w przyszłości?

Powinni przeprowadzić testy w warstwie CDN, wyraźnie określić nagłówki i skorzystać z konfiguracji CDN, które zachowują lub przepuszczają wszystkie wymagane metadane. Ponadto prowadzenie dokumentacji dotyczącej sposobu, w jaki sieci CDN zmieniają ruch, jest niezbędne na etapach debugowania.