413 Request Entity Too Large: przyczyny i naprawa

Co oznacza 413 Payload Too Large

RFC 9110 definiuje aktualną nazwę jako 413 Content Too Large, choć starsze 413 Payload Too Large i jeszcze starsze 413 Request Entity Too Large odnoszą się do tego samego kodu statusu i wciąż pojawiają się na serwerach, w frameworkach i na stronach błędów. Bez względu na sformułowanie, znaczenie jest identyczne: samo żądanie było poprawne składniowo, ale jego treść przekroczyła limit rozmiaru, zanim serwer zgodził się je przyjąć do przetworzenia. Najczęściej zdarza się to przy przesyłaniu plików, ale może zdarzyć się przy dowolnym żądaniu z dużą treścią, w tym masowym ładunku API.

Jak pojawia się błąd

Przeglądarki zwykle pokazują dowolną prostą stronę błędu odesłaną przez serwer źródłowy albo brzeg sieci; nie ma dedykowanego interfejsu przeglądarki dla tego, tak jak przy awarii połączenia. Częste jest, że zawodzi to po cichu w formularzu, z odpowiedzią widoczną tylko w zakładce sieciowej, zwłaszcza dla przesyłania plików zbudowanego w JavaScripcie. Z linii poleceń odpowiedź potwierdza to wprost:

curl -i -X POST -F "[email protected]" https://example.com/upload
HTTP/1.1 413 Request Entity Too Large
Content-Type: text/html

Logi dostępu i błędów serwera to najbardziej wiarygodne miejsce, żeby potwierdzić dokładny zaangażowany rozmiar i która warstwa go odrzuciła, bo żądanie może zostać zablokowane na CDN, serwerze WWW albo aplikacji, a każde loguje to inaczej.

Co powoduje 413

• client_max_body_size nginx. Domyślna wartość to 1 MB, co jest na tyle małe, że niemal każde prawdziwe przesyłanie pliku ją przekracza, dopóki nie zostanie jawnie podniesiona:

  client_max_body_size 20M;

• LimitRequestBody Apache. Ustawiane per katalog albo globalnie i, podobnie jak nginx, domyślnie ma rozmiar, który wiele aplikacji przekracza bez celowej zmiany przez kogokolwiek.
• upload_max_filesize i post_max_size PHP. Dwa osobne ustawienia w php.ini, które obie muszą być wystarczająco duże dla przesyłania; post_max_size musi być co najmniej tak duże jak upload_max_filesize, inaczej drugie ustawienie po cichu ogranicza pierwsze.
• maxAllowedContentLength IIS. Ustawiane w web.config pod requestLimits, domyślnie około 30 MB, i osobne od własnego ustawienia ASP.NET maxRequestLength, które używa innych jednostek i musi być podniesione razem z nim.
• Limit przesyłania oparty na planie Cloudflare. Plany Free i Pro ograniczają rozmiar treści żądania do 100 MB niezależnie od tego, co poza tym zaakceptowałby serwer źródłowy, i tego limitu nie da się podnieść z konfiguracji serwera źródłowego; trzeba to rozwiązać po stronie Cloudflare albo obejść ścieżką bezpośredniego przesyłania, która omija proxy.
• Limity ładunku bramy API. Zarządzane bramy API zwykle ograniczają treści żądań znacznie poniżej tego, na co pozwoliłby tradycyjny serwer WWW, często w niskich pojedynczych megabajtach, co łapie zespoły migrujące istniejącą funkcję przesyłania za nową bramę.

Jak rozpoznać, kto zawinił

To niemal nigdy nie jest wina odwiedzającego w sensie zrobienia czegoś złego; plik, który przesyła, jest po prostu większy niż limit istniejący gdzieś w łańcuchu, a naprawa należy do tego, kto włada tą warstwą. Jeśli ten sam plik przesyła się dobrze na jednym środowisku, a zawodzi na innym, porównaj każdą warstwę na ścieżce żądania, bo nginx, PHP i CDN mogą mieć każdy inny limit, a wygrywa najmniejszy. Uruchomienie kontroli HTTP z treścią żądania bliską zamierzonemu limitowi, wysłanej spoza Twojej sieci, potwierdza, jaki faktycznie jest efektywny sufit od końca do końca, zamiast polegać na pojedynczym pliku konfiguracji.

Jak naprawić błąd 413

Jeśli jesteś odwiedzającym

1. Skompresuj plik przed przesłaniem, zwłaszcza obrazy i wideo, które często kurczą się drastycznie bez widocznej utraty jakości przy typowych rozmiarach.
2. Podziel duże przesyłanie na mniejsze części, jeśli witryna obsługuje przesyłanie w częściach albo wznawialne, zamiast wysyłać jedno bardzo duże żądanie.
3. Sprawdź opublikowany limit przesyłania witryny, jeśli taki jest, bo część 413 działa zgodnie z zamierzeniem, a naprawą jest po prostu mniejszy plik.

Jeśli prowadzisz witrynę

1. Podnieś limit każdej warstwy razem, nie tylko jednej. Pojedyncze żądanie zwykle przechodzi przez CDN, serwer WWW i środowisko uruchomieniowe aplikacji, a najmniejszy skonfigurowany limit gdziekolwiek w tym łańcuchu wyznacza faktyczny sufit.
2. Ustaw nginx i Apache jawnie, zamiast polegać na domyślnych:

   # nginx
   client_max_body_size 20M;
   
   # Apache
   LimitRequestBody 20971520

3. Dopasuj dwa ustawienia PHP. Podnieś zarówno upload_max_filesize, jak i post_max_size, i upewnij się, że drugie jest równe albo większe od pierwszego.
4. Zaktualizuj razem requestLimits IIS i maxRequestLength ASP.NET w web.config, bo mierzą to samo w różnych jednostkach i oba wymagają podniesienia.
5. Obejdź limit planu Cloudflare dla naprawdę dużych plików, przesyłając bezpośrednio do storage'u z podpisanym URL, całkowicie omijając ścieżkę żądania przez proxy, zamiast próbować podnieść limit, którego dany poziom planu nie udostępnia.
6. Sprawdź własny limit ładunku bramy API osobno od usługi backendowej, jeśli jakaś stoi przed Twoją aplikacją; może odrzucić żądanie, zanim Twoje własne, bardziej hojne ustawienia aplikacji w ogóle dostaną szansę zadziałać.

Jak zapobiec, żeby 413 blokowało prawdziwych użytkowników

Limit ustawiony zbyt nisko łatwo przeoczyć, dopóki ktoś z dużym plikiem na niego nie trafi, a wtedy wygląda to jak zepsuta funkcja przesyłania, nie niedopasowanie konfiguracji. Zaplanowana kontrola HTTP, która wysyła żądanie bliskie zamierzonemu limitowi rozmiaru, z asercją na oczekiwanym kodzie statusu, potwierdza, że cały łańcuch wciąż to akceptuje po dowolnej zmianie CDN, serwera WWW albo konfiguracji aplikacji. W połączeniu z monitorowaniem z wielu lokalizacji wyłapuje też limit na poziomie CDN, który obowiązuje tylko na niektórych węzłach brzegowych.

Powiązane błędy

Zobacz 400 Bad Request, który niektóre serwery zwracają zamiast 413 przy tym samym warunku zbyt dużej treści, przegląd 4xx dla szerszej rodziny oraz 406 Not Acceptable gdzie indziej w tej partii.

Najczęściej zadawane pytania

Czy 413 Payload Too Large to to samo co 413 Request Entity Too Large?

Tak. RFC 9110 zmieniło tekst statusu na 413 Content Too Large, ale obie starsze nazwy odnoszą się do identycznego kodu statusu i znaczenia, a wszystkie trzy sformułowania wciąż pojawiają się w praktyce zależnie od wersji oprogramowania serwera.

Dlaczego moje przesyłanie zawodzi, mimo że podniosłem client_max_body_size w nginx?

Inna warstwa w łańcuchu, zwykle post_max_size PHP, stały limit planu CDN albo brama API, prawdopodobnie egzekwuje mniejszy limit niezależnie. Każda warstwa między klientem a aplikacją musi dopuszczać ten rozmiar, nie tylko ta, którą zmieniłeś.

Czy mogę podnieść limit 100 MB Cloudflare na planie free albo pro?

Nie z konfiguracji samego serwera źródłowego; ten sufit jest ustalony przez poziom planu. Zwykłym obejściem jest przesyłanie dużych plików bezpośrednio do storage'u za pomocą podpisanego URL, który omija ścieżkę żądania przez proxy.

Czy 413 liczy się jako blokada bezpieczeństwa?

Zwykle nie. To zwykle prosty limit zasobów, a nie reguła obronna, choć niektóre WAF-y używają nietypowo dużych treści jako jednego z kilku sygnałów przy decydowaniu, czy zablokować żądanie.

Jaki jest rozsądny domyślny limit przesyłania, jeśli go nie ustawiłem?

Nie ma uniwersalnej liczby; zależy to całkowicie od tego, co Twoja aplikacja zasadnie musi akceptować. Ustaw go świadomie na podstawie największego oczekiwanego legalnego pliku, zamiast zostawiać domyślną wartość każdej warstwy.