Opis błędu i przyczyny
ERRZSTDWINDOWSIZETOOBIG to błąd pojawiający się w przeglądarkach opartych na Chrome (począwszy od wersji 122/123), gdy strona WWW próbuje korzystać z kompresji Zstandard (zstd) do przesłania zawartości, ale rozmiar okna dekompresji przekracza limity nałożone przez przeglądarkę. Wynikiem jest zamiast wyświetlanej strony – biały, pusty ekran, a w narzędziach programistycznych widać komunikat net::ERRZSTDWINDOWSIZETOOBIG.
Błąd występuje, ponieważ przeglądarka Chrome (zwłaszcza w nowszych wersjach) domyślnie zaczyna wspierać zstd (można to sprawdzić w nagłówku Accept-Encoding: gzip, deflate, br, zstd), jednak stosowany przez serwer kompres zstd wymaga za dużo pamięci (większy window size niż 8 MiB), a przeglądarka nie pozwala na przekroczenie tego limitu.
Najczęściej problem dotyczy:
- Deployów aplikacji wykorzystujących popularne frameworki HTTP (np. konfiguracja z tower-http w projektach Rust),
- Nowych wersji Chrome (szczególnie od wersji 122/123, gdzie zstd jest domyślnie włączone),
- Serwerów, które obsługują zstd i nie są zaktualizowane do najnowszych specyfikacji kompresji.
Dla kogo ten poradnik?
- Webmasterzy i developerzy – jak wykryć, skąd się bierze błąd na swoich stronach, jak diagnozować i szybko naprawić problem,
- Użytkownicy końcowi – jak tymczasowo obejść problem, jeśli wchodzą na stronę z nowym Chrome i widzą pustą stronę.
Diagnoza – jak sprawdzić, czy to ten błąd?
- Otwórz stronę w najnowszym Chrome (wersja 122 lub nowsza).
- Otwórz narzędzia programistyczne (DevTools) (F12), przejdź do zakładki „Network”, przeładuj stronę.
- Sprawdź nagłówek Accept-Encoding w żądaniu – jeśli pojawia się zstd, to Chrome oczekuje odpowiedzi z tą kompresją.
- Znajdź błąd – jeśli pojawia się komunikat net::ERRZSTDWINDOWSIZETOO_BIG, to Twój problem został zidentyfikowany.
Naprawa – krok po kroku
Dla administrowanych serwerów (webmaster/dev)
Opcja 1: Wyłączenie obsługi zstd na serwerze
Najprostsze i najszybsze rozwiązanie to wyłączenie kompresji zstd na serwerze WWW. W najpopularniejszych frameworkach służy do tego odpowiednia flaga konfiguracyjna w middleware kompresji. Przykład dla tower-http w Rust:
// Przed: .use_compression() // Po: .use_compression(CompressionLayer::new().no_zstd()) Zapewnij, że zaktualizowana wersja zostanie wdrożona.
Opcja 2: Aktualizacja bibliotek kompresji
Jeśli Twój framework pozwala na łatwą aktualizację bibliotek wspierających zstd (np. zstd-rs/tower-http), zaktualizuj je do najnowszej wersji – być może nowa wersja już obsługuje wymagania Chrome. Niestety, nie zawsze to działa i czasem aktualizacja jest trudna lub nawet nie niweluje problemu.
Opcja 3: Przekierowanie nagłówka Accept-Encoding przez Reverse Proxy
Jeśli masz kontrolę nad warstwą proxy (np. nginx, Apache, Traefik), usuń lub zmień nagłówek Accept-Encoding w żądaniu, tak by serwer nie otrzymywał sugestii zstd i zawsze odpowiadał gzip/deflate.
Przykład dla Traefik (w Consul tag format) –
label: traefik.http.middlewares.strip-zstd.headers.AcceptEncoding='gzip, deflate, br' Zastosuj ten middleware do odpowiednich ścieżek/backendów.
Przykład dla nginx –
proxy_set_header Accept-Encoding "gzip, deflate, br"; Powtórz ten proces dla wszystkich swoich backendów korzystających z kompresji.
Opcja 4: Komunikat użytkownikom
Możesz umieścić informację dla posiadaczy nowego Chrome, by spróbowali wyłączyć eksperymentalny zstd (tylko na czas naprawy):
Jeśli strona nie ładuje się (pusta lub biała), spróbuj w adresie wpisać:
chrome://flags/#enable-zstd-content-encoding
i ustaw wartość na Disabled.
Dla użytkowników końcowych
Jeśli jako użytkownik końcowy masz problem z otwieraniem strony w nowym Chrome, możesz:
- Wyłączyć eksperymentalny zstd w ustawieniach przeglądarki:
- Wejdź na
chrome://flags/#enable-zstd-content-encoding - Ustaw wartość na Disabled i zrestartuj przeglądarkę
- Spróbuj otworzyć stronę w innej przeglądarce (Firefox, Edge, Safari),
- Daj znać właścicielowi strony, jeśli problem dotyczy wielu osób – najlepiej podaj link do tej instrukcji.
Dodatkowe wyjaśnienia i FAQ
Dlaczego to się dzieje?
Chrome w wersjach 122+ domyślnie wspiera zstd, ale narzuca ścisły limit na rozmiar okna dekompresji (8 MiB). Jeśli serwer wygeneruje strumień zstd z oknem większym niż ten limit, Chrome odmawia jego dekompresji i wyświetla błąd ERRZSTDWINDOWSIZETOO_BIG.
Czy każdy serwer z zstd jest zagrożony?
Nie. Problem dotyczy serwerów, które w obecnej wersji natywnie obsługują zstd, ale ich implementacja jeszcze nie współpracuje z ograniczeniami nowych przeglądarek.
Czy wyłączenie zstd pogorszy wydajność?
Wyłączenie zstd sprawi, że strony będą kompresowane tylko przez gzip/deflate/br, które są szeroko wspierane i w większości przypadków wystarczająco skuteczne. Utrata zstd może nieznacznie zmniejszyć stopień kompresji, ale nie powoduje pogorszenia funkcjonalności.
Czy inne przeglądarki są bezpieczne?
Na tym etapie tylko Chrome (i na przykład Edge jako oparty na Chromium) wprowadził domyślną obsługę zstd. Firefox, Safari i starsze Chrome są bezpieczne do czasu aktualizacji.
Podsumowanie
ERRZSTDWINDOWSIZETOO_BIG to błąd kompatybilności między nowym Chrome a serwerami WWW implementującymi zstd w sposób przekraczający limity przeglądarki. Najważniejsze kroki naprawcze to wyłączenie zstd na serwerze, aktualizacja bibliotek lub modyfikacja nagłówka Accept-Encoding przez reverse proxy. Użytkownicy końcowi mogą tymczasowo wyłączyć eksperymentalny zstd w ustawieniach przeglądarki.
W razie potrzeby monitoruj status aktualizacji bibliotek i standardu – w przyszłości nowe wersje będą zapewne zgodne z wymaganiami Chrome.
Źródła –
GitHub issue kanidm/kanidm #2593 (detailed technical explanation and workarounds).
[Dodatkowe materiały na temat zstd w aplikacjach sieciowych i diagnostyki błędów w implementacjach kompresji.]
