413 Request Entity Too Large: причини і виправлення

Що означає 413 Payload Too Large

RFC 9110 визначає поточну назву як 413 Content Too Large, хоча і 413 Payload Too Large, і старіший 413 Request Entity Too Large обидва посилаються на той самий код статусу й досі трапляються на серверах, у фреймворках і на сторінках помилок. Хоч би яке формулювання, значення ідентичне: сам запит був синтаксично в порядку, але його тіло перевищило ліміт розміру, перш ніж сервер погодився б прийняти його на обробку. Найчастіше це трапляється при завантаженні файлів, але може трапитися з будь-яким запитом із великим тілом, включно з масовим тілом API.

Як з'являється помилка

Браузери зазвичай показують будь-яку просту сторінку помилки, яку повернув origin-сервер чи edge-вузол; окремого інтерфейсу браузера для цього, як для збою з'єднання, немає. Часто це мовчки провалюється у формі, а відповідь видно лише у вкладці мережі, особливо для завантаження файлу, побудованого на JavaScript. З командного рядка відповідь підтверджує це прямо:

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

Логи доступу й помилок сервера - найнадійніше місце, щоб підтвердити точний задіяний розмір і який саме шар відхилив запит, оскільки запит можуть заблокувати на CDN, вебсервері чи в застосунку, і кожен логує це по-своєму.

Що спричиняє 413

• client_max_body_size у nginx. За замовчуванням 1 МБ, що достатньо мало, щоб майже будь-яке справжнє завантаження файлу спрацьовувало на ньому, доки його явно не піднімуть:

  client_max_body_size 20M;

• LimitRequestBody у Apache. Встановлюється для окремої директорії чи глобально, і, як і nginx, за замовчуванням має розмір, який багато застосунків перевищують без того, щоб хтось навмисно це змінював.
• upload_max_filesize і post_max_size у PHP. Два окремих налаштування в php.ini, обидва мають бути достатньо великими для завантаження; post_max_size має бути принаймні таким же великим, як upload_max_filesize, інакше друге налаштування мовчки обмежує перше.
• maxAllowedContentLength у IIS. Встановлюється в web.config під requestLimits, за замовчуванням близько 30 МБ, і окремо від власного налаштування ASP.NET maxRequestLength, яке використовує інші одиниці й потребує підняття разом з ним.
• Ліміт завантаження Cloudflare залежно від плану. Плани Free і Pro обмежують розмір тіла запиту 100 МБ незалежно від того, що інакше прийняв би origin-сервер, і цей ліміт не можна підняти з власної конфігурації origin-сервера; його потрібно вирішувати на боці Cloudflare чи обходити прямим шляхом завантаження, що оминає проксі.
• Ліміти тіла запиту API-шлюзу. Керовані API-шлюзи зазвичай обмежують тіла запитів значно нижче за те, що дозволив би традиційний вебсервер, часто на рівні одноцифрових мегабайтів, що ловить команди, які переносять наявну функцію завантаження за новий шлюз.

Як зрозуміти, хто винен

Це майже ніколи не вина відвідувача в сенсі того, що він зробив щось не так; файл, який він завантажує, просто більший за ліміт, що існує десь у ланцюжку, і виправлення належить тому, хто володіє цим шаром. Якщо той самий файл нормально завантажується в одному середовищі й провалюється в іншому, порівняйте кожен шар у шляху запиту, оскільки nginx, PHP і CDN можуть мати різні ліміти, і перемагає найменший. Запуск HTTP-перевірки з тілом запиту, близьким до вашого запланованого ліміту, надісланої ззовні вашої мережі, підтверджує, яка справжня стеля наскрізь, а не покладання на якийсь окремий конфігураційний файл.

Як виправити помилку 413

Якщо ви відвідувач

1. Стисніть файл перед завантаженням, особливо зображення й відео, що часто суттєво зменшуються без видимої втрати якості за типових розмірів.
2. Розділіть велике завантаження на менші частини, якщо сайт підтримує завантаження частинами чи з можливістю відновлення, замість надсилання одного дуже великого запиту.
3. Перевірте заявлений ліміт завантаження сайту, якщо такий опублікований, оскільки деякі 413 працюють так, як задумано, і виправлення - просто менший файл.

Якщо ви керуєте сайтом

1. Піднімайте ліміт кожного шару разом, а не лише одного. Один запит зазвичай проходить через CDN, вебсервер і середовище виконання застосунку, і найменший налаштований ліміт будь-де в цьому ланцюжку визначає фактичну стелю.
2. Явно встановіть nginx і Apache, а не покладайтеся на значення за замовчуванням:

   # nginx
   client_max_body_size 20M;
   
   # Apache
   LimitRequestBody 20971520

3. Узгодьте два налаштування PHP. Підніміть і upload_max_filesize, і post_max_size, і переконайтеся, що друге дорівнює першому чи більше за нього.
4. Оновіть requestLimits IIS і maxRequestLength ASP.NET разом у web.config, оскільки вони вимірюють те саме в різних одиницях, і обидва потребують підняття.
5. Обходьте ліміт плану Cloudflare для справді великих файлів, завантажуючи напряму в сховище через підписану URL-адресу, повністю оминаючи проксійований шлях запиту, замість спроби підняти ліміт, якого цей рівень плану не відкриває.
6. Перевіряйте власний ліміт тіла запиту API-шлюзу окремо від бекенд-служби, якщо він стоїть перед вашим застосунком; він може відхилити запит ще до того, як власні, щедріші налаштування вашого застосунку взагалі отримають шанс застосуватися.

Як запобігти, щоб 413 не блокував реальних користувачів

Ліміт, встановлений надто низько, легко пропустити, доки хтось із великим файлом на нього не натрапить, а на той момент це виглядає як зламана функція завантаження, а не невідповідність конфігурації. Запланована HTTP-перевірка, що надсилає запит близький до вашого запланованого ліміту розміру, з умовою на очікуваний код статусу, підтверджує, що весь ланцюжок усе ще приймає його після будь-якої зміни в CDN, вебсервері чи конфігурації застосунку. У поєднанні з моніторингом з кількох локацій це також ловить ліміт на рівні CDN, що застосовується лише на певних edge-вузлах.

Пов'язані помилки

Дивіться 400 Bad Request, який деякі сервери повертають замість 413 за тієї самої умови завеликого тіла, огляд 4xx для ширшої родини, і 406 Not Acceptable деінде в цій партії.

Часті запитання

Чи 413 Payload Too Large - те саме, що 413 Request Entity Too Large?

Так. RFC 9110 перейменував текст статусу на 413 Content Too Large, але обидві старіші назви посилаються на ідентичний код статусу й значення, і всі три формулювання досі трапляються залежно від версії програмного забезпечення сервера.

Чому моє завантаження провалюється, навіть коли я підняв client_max_body_size у nginx?

Інший шар у ланцюжку, зазвичай post_max_size у PHP, фіксований ліміт плану CDN чи API-шлюз, найімовірніше, незалежно застосовує менший ліміт. Кожен шар між клієнтом і застосунком має дозволяти цей розмір, а не лише той, що ви змінили.

Чи можу я підняти ліміт 100 МБ Cloudflare на безкоштовному чи pro-плані?

Не з власної конфігурації origin-сервера; ця стеля фіксована рівнем плану. Звичайний обхід - завантаження великих файлів напряму в сховище за допомогою підписаної URL-адреси, що оминає проксійований шлях запиту.

Чи вважається 413 блокуванням безпеки?

Зазвичай ні. Це, як правило, простий ліміт ресурсу, а не захисне правило, хоча деякі WAF справді використовують незвично великі тіла як один із кількох сигналів при вирішенні, чи блокувати запит.

Який розумний ліміт завантаження за замовчуванням, якщо я його не встановлював?

Універсального числа немає; це повністю залежить від того, що ваш застосунок легітимно має приймати. Встановлюйте його свідомо на основі найбільшого очікуваного легітимного файлу, а не лишайте значення за замовчуванням кожного шару як є.