413 Request Entity Too Large: příčiny a opravy

Co znamená 413 Payload Too Large

RFC 9110 přejmenovává aktuální název na 413 Content Too Large, i když se starší 413 Payload Too Large a 413 Request Entity Too Large obě vztahují na stejný stavový kód a pořád se objevují napříč servery, frameworky i chybovými stránkami. Ať už je znění jakékoli, význam je identický: samotný požadavek byl syntakticky v pořádku, ale jeho tělo překročilo limit velikosti dřív, než ho server přijal ke zpracování. Nejčastěji se to stává při nahrávání souborů, ale může se to stát u jakéhokoli požadavku s velkým tělem, včetně hromadného obsahu API.

Jak se chyba projevuje

Prohlížeče obvykle zobrazí jakoukoli obyčejnou chybovou stránku, kterou pošle zpátky origin server nebo edge; pro tohle neexistuje žádné vyhrazené rozhraní prohlížeče jako u selhání spojení. Je běžné vidět to potichu selhat ve formuláři, kdy je odpověď vidět jen na kartě sítě, zvlášť u nahrávání souboru postaveného v JavaScriptu. Z příkazové řádky to odpověď potvrdí přímo:

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

Přístupové a chybové logy serveru jsou nejspolehlivější místo, kde potvrdit přesnou zapojenou velikost a která vrstva to odmítla, protože požadavek může být zablokovaný na CDN, webovém serveru, nebo aplikaci, a každá z nich to zaznamenává jinak.

Co způsobuje 413

• client_max_body_size v nginx. Výchozí hodnota je 1 MB, což je dost malé na to, aby na to narazilo skoro každé skutečné nahrání souboru, dokud se výslovně nezvýší:

  client_max_body_size 20M;

• LimitRequestBody v Apache. Nastavuje se podle adresáře nebo globálně, a stejně jako nginx má ve výchozím stavu velikost, kterou hodně aplikací přesáhne, aniž by to kdokoli záměrně změnil.
• upload_max_filesize a post_max_size v PHP. Dvě samostatná nastavení v php.ini, která obě musí být dost velká pro dané nahrání; post_max_size musí být aspoň tak velké jako upload_max_filesize, jinak druhé nastavení první potichu ořízne.
• maxAllowedContentLength v IIS. Nastavuje se v web.config pod requestLimits, ve výchozím stavu asi 30 MB, a je oddělené od vlastního nastavení maxRequestLength ASP.NET, které používá jiné jednotky a musí se zvýšit spolu s ním.
• Limit nahrávání Cloudflare podle plánu. Plány Free a Pro omezují velikost těla požadavku na 100 MB bez ohledu na to, co by jinak přijal origin server, a tenhle limit nejde zvýšit z vlastní konfigurace originu; musí se to řešit na straně Cloudflare, nebo obejít přímou cestou nahrávání, která proxy obchází.
• Limity obsahu brány API. Spravované brány API běžně omezují těla požadavků výrazně pod to, co by povolil tradiční webový server, často v řádu jednotek megabajtů, což zasáhne týmy migrující existující funkci nahrávání za novou bránu.

Jak zjistit, čí je to chyba

Tohle skoro nikdy není chyba návštěvníka v tom smyslu, že by udělal něco špatně; soubor, který nahrává, je prostě větší než limit, který někde v řetězci existuje, a oprava patří tomu, kdo tuhle vrstvu vlastní. Pokud se stejný soubor v jednom prostředí v pořádku nahraje a v jiném selže, porovnejte každou vrstvu na cestě požadavku, protože nginx, PHP a CDN mohou mít každý jiný limit a vyhraje ten nejmenší. Spuštění HTTP kontroly s tělem požadavku blízkým vašemu zamýšlenému limitu, odeslané zvenčí vaší sítě, potvrdí, jaký je skutečný strop celou cestou, místo aby se spoléhalo na jediný konfigurační soubor.

Jak opravit chybu 413

Pokud jste návštěvník

1. Zkomprimujte soubor před nahráním, zvlášť obrázky a videa, které se u typických velikostí často výrazně zmenší bez viditelné ztráty kvality.
2. Rozdělte velké nahrání na menší části, pokud web podporuje nahrávání po částech nebo obnovitelné nahrávání, místo posílání jednoho velmi velkého požadavku.
3. Zkontrolujte uvedený limit nahrávání webu, pokud je nějaký zveřejněný, protože některé 413 fungují přesně podle záměru a oprava je prostě menší soubor.

Pokud web provozujete

1. Zvyšte limit v každé vrstvě společně, ne jen v jedné. Jeden požadavek obvykle prochází přes CDN, webový server, a běhové prostředí aplikace, a nejmenší nastavený limit kdekoli v tomhle řetězci určuje skutečný strop.
2. Nastavte nginx a Apache výslovně, místo abyste se spoléhali na výchozí hodnoty:

   # nginx
   client_max_body_size 20M;
   
   # Apache
   LimitRequestBody 20971520

3. Sesouhlaste dvě nastavení PHP. Zvyšte upload_max_filesize i post_max_size a ujistěte se, že druhé je rovné nebo větší než první.
4. Aktualizujte requestLimits IIS a maxRequestLength ASP.NET společně v web.config, protože měří stejnou věc v jiných jednotkách a obě je potřeba zvýšit.
5. Obejděte limit plánu Cloudflare u skutečně velkých souborů nahráním přímo do úložiště pomocí podepsané URL, která proxírovanou cestu požadavku úplně obejde, místo abyste se snažili zvýšit limit, který daný stupeň plánu nenabízí.
6. Zkontrolujte vlastní limit obsahu brány API odděleně od backendové služby, pokud je před vaší aplikací nějaká nasazená; může odmítnout požadavek dřív, než vůbec dostane šanci se uplatnit vaše vlastní, velkorysejší nastavení aplikace.

Jak předejít tomu, aby 413 blokovala skutečné uživatele

Příliš nízko nastavený limit je snadné přehlédnout, dokud na něj nenarazí někdo s velkým souborem, a do té doby to vypadá jako rozbitá funkce nahrávání, ne jako nesoulad konfigurace. Naplánovaná HTTP kontrola, která odesílá požadavek blízký vašemu zamýšlenému limitu velikosti, s ověřením očekávaného stavového kódu, potvrdí, že ho celý řetězec pořád přijímá po jakékoli změně CDN, webového serveru, nebo konfigurace aplikace. V kombinaci s monitoringem z více míst taky zachytí limit na úrovni CDN, který se uplatňuje jen na určitých edge uzlech.

Související chyby

Viz 400 Bad Request, kterou některé servery vrací místo 413 pro stejný stav předimenzovaného těla, přehled 4xx pro širší rodinu, a 406 Not Acceptable jinde v této dávce.

Často kladené otázky

Je 413 Payload Too Large totéž jako 413 Request Entity Too Large?

Ano. RFC 9110 přejmenovalo text stavu na 413 Content Too Large, ale oba starší názvy odkazují na identický stavový kód a význam, a všechna tři znění se pořád objevují v praxi podle verze softwaru serveru.

Proč mi nahrávání pořád selhává, i když jsem zvýšil client_max_body_size v nginx?

Jiná vrstva v řetězci, běžně post_max_size v PHP, pevný limit plánu CDN, nebo brána API, pravděpodobně nezávisle vynucuje menší limit. Velikost musí povolovat každá vrstva mezi klientem a aplikací, ne jen ta, kterou jste změnili.

Můžu zvýšit limit 100 MB Cloudflare na plánu free nebo pro?

Ne z vlastní konfigurace origin serveru; tenhle strop je pevně daný stupněm plánu. Obvyklé řešení je nahrávat velké soubory přímo do úložiště pomocí podepsané URL, která proxírovanou cestu požadavku obchází.

Počítá se 413 jako bezpečnostní blokace?

Obvykle ne. Většinou jde o přímočarý limit zdrojů, ne obrannou pravidlo, i když některé WAF skutečně používají neobvykle velká těla jako jeden signál z několika při rozhodování, jestli požadavek zablokovat.

Jaký je rozumný výchozí limit nahrávání, když jsem žádný nenastavil?

Neexistuje univerzální číslo; závisí to úplně na tom, co vaše aplikace legitimně potřebuje přijímat. Nastavte ho záměrně na základě svého největšího očekávaného legitimního souboru, místo abyste nechali výchozí hodnotu v každé vrstvě beze změny.