Request failed with status code 413

03.09.202203.09.2022 admin 0 Comments

Request failed with status code 413

413/414 Request URL/Entity Too Large Error Nginx

what is 413/414 request URL/entity too large issue?

Ever tried to upload a huge file or send a very large payload in the request?

If yes, you must have received status code 413 from nginx saying that the “request entity is too large for nginx to handle”.

The reason for this error response is because of the “ client_max_body_size” parameter in the nginx configuration.

Web servers keep a limit on the maximum size of the request that can be sent to them. This is handled using client_max_body_size parameter. That is because, as mentioned in this stack exchange answer and I quote —

If you configure “ client_body_max_size» to a large value, then you are putting your server in the same scenario as by 2013 when Django allowed users to use a very long password forcing Django (rather the server where it is hosted) to perform very expensive hash calculations leading, as you may guess, to a denial-of-service attack against the whole Django’s authentication framework.

In nginx documentation, By default the value of client_body_max_size is 1 MiB.

If it is a requirement to change client_body_max_size in nginx configuration, It can be done in the following way:

There you go, the maximum permitted request size in nginx configuration has been changed.

HTTP 414 request-URI too large

The HTTP 414 URI Too Long response status code indicates that the URI requested by the client is longer than the server is willing to interpret.

Talking in terms of “Nginx” web server. This can also be handled in the similar manner as HTTP 413 error. To handle this we have to modify large_client_header_buffers parameter in the server configuration.

As mentioned in the documentation, default size of large_client_header_buffers is 8 KB.

This way you errors pertaining to max size of request payload or request URI can be handled.

AviaCommerce is an open source e-commerce framework written in Elixir, it leverages all the benefits of the battle-tested Erlang runtime mainly high availability and massive scalability. Do check out the Github repository, where all the action happens!

If you enjoyed this tutorial, please click the 👏 button and share to help others find it! Feel free to leave a comment below.

Ошибка 413 request entity too large Nginx

В данной небольшой статье будет рассмотрено описание ошибки 413 Request Entity Too Large а также методы её исправления на стороне веб-сервера Nginx.

Что означает ошибка 413 Request Entity Too Large

Ошибка 413 Request Entity Too Large дословно расшифровывается как объект запроса слишком велик или простыми словами объем передаваемых данных слишком большой. Данная ошибка возвращается в случае, если сервер не может обработать запрос по причине слишком большого размера тела запроса (или большого файла). Снимок экрана с ошибкой изображен ниже:

По умолчанию в Nginx установлен лимит на размер тела запроса который равен 1 МБ. Если запрос превышает установленное значение, вы увидите ошибку 413 Request Entity Too Large.

Как исправить ошибку 413 Request Entity Too Large

Для того чтобы исправить данную ошибку необходимо увеличить допустимый лимит. Чтобы увеличить размер тела запроса и соответственно, загружаемых файлов, необходимо использовать параметр client_max_body_size. Данную опцию можно использовать в директивах http, server или location в конфигурационном файле /etc/nginx/nginx.conf или в конфигурационном файле веб-сайта.

Для этого необходимо открыть конфигурационный файл nginx.conf при помощи любого текстового редактора (например nano):

sudo nano /etc/nginx/nginx.conf

Далее впишите такую строчку в секцию http:

Если ограничение на загрузку необходимо выставить только для конкретного сайта, то строку client_max_body_size необходимо добавить в блок server конфигурационного файла сайта, который по умолчанию находиться в /etc/nginx/sites-available/имя_файла_с_конфигурацией:

Если ограничение на загрузку необходимо выставить только для конкретного раздела на сайте, строку client_max_body_size необходимо вписать в директиву location конфигурационного файла сайта, который по умолчанию находиться в /etc/nginx/sites-available/имя_файла_с_конфигурацией:

После внесения изменений в конфигурационные файлы необходимо сохранить изменения, закрыть текстовый редактор и проверить синтаксис конфигурационных файлов на наличие ошибок при помощи команды:

Если в выводе команды будут отображены следующие строки:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Это означает что ошибок нет. В противном случае будет выведено описание ошибки, имя файла в котором найдена ошибка и номер строки. После внесения любых изменений в конфигурационные файлы Nginx их необходимо перезапустить при помощи команды:

sudo systemctl reload nginx

Выводы

В данной короткой статье была рассмотрена ошибка в Nginx под названием 413 Request Entity Too Large которая возникает при загрузке больших файлов на веб-сайт. Помимо описания самой ошибки также было описаны шаги по устранению ошибки путем редактирования конфигурационных файлов Nginx.

Как исправить ошибку 413 Request Entity Too Large

При загрузке файла в свой блог, столкнулся с ошибкой «413 Request Entity Too Large». Быстрое гугление показало, что для исправления, нужно чуть поднастроить веб-сервер..

Что означает ошибка «413 Request Entity Too Large»

Ошибка » 413 Request Entity Too Large » переводится как «Размер запроса слишком большой» возникает когда размер запроса от клиента превышает максимальные ограничения установленные для обработки на стороне веб-сервера. Такие ограничение применяют для защиты от атак направленных на увеличение нагрузки на веб-сервер.

Например, в моем случае, я попытался загрузить gif-ку размер которой был около 2 мб. Соответственно мой браузер отправил POST запрос на веб-сервер, примерно такого же размера. В результате я получил ошибку «R equest entity too large » от веб-сервера, о том, что мой запрос слишком большой для дальнейшей обработки.

Как исправить ошибку «413 Request Entity Too Large» со стороны клиента

Самый простой способ, это уменьшить размер запроса. Тут многое зависит от того, что именно вы отправляете на сервер.

Если это форма с несколькими файлами, попробуйте загружать файлы по одному.

Если это какие-то документы и есть возможность, попробуйте их заархивировать.

Если это картинка, попробуйте её сохранить в другом формате, например уменьшить разрешение и сохранить в JPG.

Как исправить ошибку «413 Request Entity Too Large» на стороне Nginx веб-сервера

Разумеется, можно поправить конфигурацию веб-сервера, если у вас есть к ней доступ, чтобы избежать таких ошибок в дальнейшем.

В nginx, за это отвечает опция client_max_body_size: http://nginx.org/en/docs/http/ngx_http_core_module.html#client_max_body_size
Значение по-умолчанию: 1Мб

Данную опцию можно использовать в следующих контекстах: http, server, location. Т.е. можно задать глобальное значение, значение для домена и значение для конкретного адреса url.

Я решил увеличить глобальное значение, т.к. это исправит проблему сразу для нескольких блогов, расположенных в рамках одного сервера.

Для этого добавляем нужное значение (в моем случае это 16 Мб) в главный файл конфигурации

I am trying to upload 30MB file on my server and its not working.

When I upload 30MB file, the page loads «Page Not Found«

When I upload a 3MB file, I receive «413 Request Entity Too Large» with nginx/0.6.32

I am trying to find nginx so I can increase «client_max_body_size» but I am unable to find nginx installed on my server. I even tried running:

to check if the config file exists, but I couldnt find it on my server.

Is there anyway to resolve this issue? Or do I have to installed nginx on my server.

I have made all necessary changes in my php.ini files,

12 Answers 12

Trending sort

Trending sort is based off of the default sorting method — by highest score — but it boosts votes that have happened recently, helping to surface more up-to-date answers.

It falls back to sorting by highest score if no posts are trending.

Switch to Trending sort

Edit the conf file of nginx:

Doen’t use MB it will not work, only the M!

Also do not forget to restart nginx

-in php.ini (inside /etc/php.ini)

-in nginx.conf(inside /opt/nginx/conf)

Its working for my case

First edit the Nginx configuration file ( nginx.conf )

Location: sudo nano /etc/nginx/nginx.conf

Add following codes:

Then Add the following lines in PHP configuration file( php.ini )

Location: sudo gedit /etc/php5/fpm/php.ini

Add following codes:

Then add a line in the http section

don’t use MB only M.

then for php location

for nowdays maximum use php 7.0 or higher

I add the changes directly to my virtualhost instead the global config of nginx, like this:

And then I change the params in php.ini, like the comments above:

and what you can not forget is to restart nginx and php-fpm, in centos 7 is like this:

Please enter domain nginx file :

Add to file this code

If you get error use this command

I got the same error and fixed it with the below steps.

At first, edit the nginx.conf file.

At the HTTP section, added the below line.

systemctl restart nginx

Assuming that you made the necessary changes in your php.ini files:

You can resolve the issue by adding the following line in your nginx.conf file found in the following path:

then edit the file using vim text editor as follows:

and add client_max_body_size with a large enough value, for example:

After that make sure you save using :xi or :wq

And then restart your nginx.

Worked for me, hope this helps.

I got the upload working with above changes. But when I made the changes I started getting 404 response in file upload which lead me to do further debugging and figured out its a permission issue by checking nginx error.log

Solution:

Check the current user and group ownership on /var/lib/nginx.

drwx——. 3 nginx nginx 17 Oct 5 19:31 /var/lib/nginx

This tells that a possibly non-existent user and group named nginx owns this folder. This is preventing file uploading.

Ошибка 413 Request Entity Too Large: что это за ошибка и как ее исправить

Ошибка HTTP 413 Request Entity Too Large появляется, когда пользователь пытается загрузить на сервер слишком большой файл. Размер определяется относительно лимита, который установлен в конфигурации. Изменить его может только администратор сервера.

Что делать, если вы пользователь

Если вы видите ошибку 413, когда пытаетесь загрузить файл на чужом сайте, то вам нужно уменьшить размер передаваемых данных. Вот несколько ситуаций.

Универсальный вариант — архивация файла со сжатием. Ошибка сервера 413 появляется только в том случае, если вы пытаетесь одновременно загрузить слишком большой объем данных. Поэтому и выход во всех ситуациях один — уменьшить размер файлов.

Исправление ошибки сервера 413 владельцем сайта

Если вы владелец сайта, который при загрузке файлов выдает ошибку 413, то необходимо изменить конфигурацию сервера. Порядок действий зависит от используемых технологий.

Увеличение разрешенного размера для загрузки файлов на Nginx и Apache

На Nginx максимально допустимый размер файла задан в параметре client_max_body_size. По умолчанию он равен 1 МБ. Если запрос превышает установленное значение, пользователь видит ошибку 413 Request Entity Too Large.

Параметр client_max_body_size находится в файле nginx.conf. Для его изменения нужен текстовый редактор — например, vi.

Подключитесь к серверу через SSH и выполните в консоли следующую команду:

Во встроенном редакторе vi откроется файл nginx.conf. В разделе http добавьте или измените следующую строку:

Сохраните и закройте файл. Затем проверьте конфигурацию файла:

Перезагрузите сервер следующей командой:

После перезагрузки будет действовать новая конфигурация с увеличенным лимитом на размер загружаемого файла.

На Apache опция, устанавливающая максимально допустимый размер загружаемого файла, называется LimitRequestBody. По умолчанию лимит не установлен (равен 0).

На CentOS главный конфиг располагается по адресу /etc/httpd/conf/httpd.conf. На Debian/Ubuntu — по адресу /etc/apache2/apache2.conf.

Значение задается в байтах:

Эта запись выставляет максимально допустимый размер 32 МБ.

Изменить конфиги можно также через панель управления. Я пользуюсь ISPmanager, поэтому покажу на ее примере.

Появится вкладка с конфигами Apache и Nginx. Вы можете редактировать их вручную, устанавливая лимит на размер загружаемого файла.

Исправление ошибки на WordPress

На WordPress ошибку можно исправить двумя способами.

Способ первый — изменение разрешенного размера в файле functions.php. Этот файл отвечает за добавление функций и возможностей — например, меню навигации.

В панели управления на Timeweb м ожно также воспользоват ься встроенным редактором или IDE — путь будет такой же, как указан выше: public.html/wp-content/themes/ваша тема/functions.php.

В конце файла functions.php добавьте следующий код:

Сохраните изменения и загрузите модифицированный файл обратно на сервер. Проверьте, появляется ли ошибка 413.

Сохраните файл и загрузите его обратно на сервер с заменой исходного файла. То же самое можно сделать через встроенный редактор или IDE в панели управления Timeweb.

Исправление ошибки при использовании PHP-скрипта

Если файлы загружаются с помощью PHP-скрипта, то для исправления ошибки 413 нужно отредактировать файл php.ini. В нем нас интересуют три директивы.:

Например, если я хочу, чтобы пользователи могли загружать файлы размером до 20 МБ, то я делаю так:

Если все значения указаны верно, то файлы с допустимым размером будут загружаться на сервер без ошибок.

То же самое можно сделать через панель управления. Например, в ISPmanager порядок будет такой:

На экране появится список параметров. Они отсортированы по алфавиту. Установите необходимые значения для параметров max_execution_time, post_max_size и upload_max_filesize. Изменения применяются автоматически.

What Is a 413 Request Entity Too Large Error & How to Fix It

Updated: May 16, 2022

Published: October 05, 2021

When building and maintaining a website, you’re bound to encounter some unexpected HTTP errors here and there. Problems like these are tough to avoid, and some are trickier to resolve than others.

If you’re experiencing a «413 Request Entity Too Large» error, the good news is that this issue is quick and simple to address — you just need to do a bit of server reconfiguration. And no, you don’t need to be a technical expert. Let’s learn how.

What does “413 Request Entity Too Large” mean?

A 413 HTTP error code occurs when the size of a client’s request exceeds the server’s file size limit. This typically happens when a client attempts to upload a large file to a web server, and the server responds with a 413 error to alert the client.

Web servers place size limits on uploads to prevent users from overwhelming the server and exceeding storage permissions. This limit usually isn’t an issue, and common website files should stay well under it. However, especially large file uploads may occasionally exceed the limit, resulting in a message like this:

While you can reduce the size of your upload to get around the error, it’s also possible to change your file size limit with some server-side modification.

How to Fix a “413 Request Entity Too Large” Error

Your default upload size limit will depend on how your server is set up. In this guide, we’ll show you how to fix a 413 error by increasing your size limit with a WordPress setup, as well as with an Apache or Nginx server configuration.

All methods require some edits to your server files, so we recommend creating a backup before attempting the steps below.

WordPress

Themes and plugins are common causes of the 413 error with the WordPress content management system. Fortunately, there are several ways to increase your WordPress upload size limit enough to let these larger files through. As long as you do not exceed the limits of your hosting plan, you can try any of the following:

Modify PHP.ini

The easiest method to increase your upload limit is by modifying your server’s PHP.ini file. Here, you can change your limit through the cPanel interface without any coding. To do this:

1. In your cPanel menu, select MultiPHP INI Editor under Software.

2. In the window that appears, choose your domain from the dropdown menu.

3. Change the values of the following parameters to your preference:

4. When finished, click Apply.

If your WordPress site is hosted on an Apache server, it’s also possible to increase your server’s limit via .htaccess, a file that contains many directives for the server. See the solution below.

Modify functions.php

You can also try increasing your size limit via the functions.php file of your current WordPress theme.

If you want to make this change permanent, we recommend trying the above approaches first. With this approach, you’ll need to update functions.php whenever you update or change your current theme.

1. In your cPanel menu, select File Manager under Files.

2. Navigate to the folder of your current theme inside your root WordPress directory (public_html by default). Open this theme file.

3. Select functions.php and click the Edit icon.

4. Copy the code below and paste it at the end of the file

5. Click Save.

This code sets the maximum allowed size of your WordPress uploads and posts to 64 megabytes. You can change this number to something larger or smaller if you need, as long as you do not exceed your hosting plan’s storage limit.

It also sets the maximum period your uploads can take to 300 seconds. Feel free to change this as well.

Nginx Server

Nginx server settings can be modified inside the file nginx.conf. Open this file and check for the directive client_max_body_size. Then, change the value (in megabytes) to your maximum file size preference.

If you do not see this directive in nginx.conf, you can add it to the end of a server, location, or http block like so:

This allows for a 64-megabyte upload. Set this number to your preference, save the file, then reload Nginx for the change to take effect.

Apache Server

Change the size limit on an Apache server by updating your .htaccess file like so:

1. In your cPanel menu, select File Manager under Files.

2. In your root WordPress directory (public_html by default), locate .htaccess. Depending on your settings, the .htaccess file may be hidden.

3. Select .htaccess and click the Edit icon.

4. Copy and paste the code below at the bottom of your .htaccess file:

5. Click Save and reload Apache.

Doing this sets the maximum allowed size of your WordPress uploads and posts to 64 megabytes and sets the maximum file upload time to 300 seconds. You can change both of these values to your preference.

Still getting a 413?

After trying one or more of the solutions above, you still may encounter a 413 error when uploading large files, even if these files are below your new size limit.

In this case, the issue may stem from your CDN’s servers or some other restriction set by your hosting provider. First, reach out to your hosting support, detailing the problem and the steps you’ve taken so far to resolve it. It may be that you’ve exceeded your plan’s file size limit without realizing. Or, your configurations may have inadvertently caused another error.

If you use a CDN to improve your site’s performance, this may also be the cause of your issue — the CDN servers you’re using may impose file size limits that are too small. Since you probably can’t modify these servers’ files directly, you consult the documentation for your CDN provider or contact product support to resolve the error.

If all else fails, consider uploading alternative files, reducing the size of your current file, or upgrading your storage plan. If you find yourself needing to upload a massive amount of data, more likely than not there’s a workaround.

Fixing a 413 Error

While HTTP errors can be frustrating, many are quickly solvable including a 413. By finding and tackling this issue now, you’ll have one less thing to worry about while building out your website. If your site allows users to upload their own content, changing your upload size limit solves this problem too — just make sure you’re not exceeding the limits set by your hosting plan.

As for the best option, we recommend WordPress users modify their server’s PHP.ini file first if possible, since this can easily be done through your hosting panel. Otherwise, choose the option that matches your server software.

This post was originally published in January 2021 and has been updated for comprehensiveness.

📑 Исправляем ошибку «413 Request Entity Too Large»

Ошибка HTTP 413 (Request Entity Too Large Error) означает, что клиент отправил слишком большой запрос на сервер.

Ошибка может возникать при отправке серверу запросов большого объёма (загрузке файлов, к примеру).

При работе с WordPress появляется довольно часто.

Одна из причин — это дефолтные настройки nginx, а точнее параметра client_max_body_size, который по умолчанию равен 1m, то-есть появляется при загрузке файлов больше 1 мегабайта.

Вообще дефолтные настройки — это всегда плохо…

Вот, что по этому поводу говорится на сайте nginx:

Задаёт максимально допустимый размер тела запроса клиента, указываемый в поле “Content-Length” заголовка запроса. Если размер больше заданного, то клиенту возвращается ошибка 413 (Request Entity Too Large).

Следует иметь в виду, что браузеры не умеют корректно показывать эту ошибку. Установка параметра размер в 0 отключает проверку размера тела запроса клиента.

Решение проблемы nginx «413 Request Entity Too Large»

где, 100M — максимальный объём запроса (файла). В данном случае — 100 мегабайт. Приставка M — мегабайты, G — гигабайты. В принципе можно задать и больше, например 512мб.

413 Request Entity Too Large

I use nginX/1.6 and laravel when i posted data to server i get this error 413 Request Entity Too Large. i tried many solutions as bellow

After restarting php5-fpm and nginx the problem still not solved

4 Answers 4

Trending sort

Trending sort is based off of the default sorting method — by highest score — but it boosts votes that have happened recently, helping to surface more up-to-date answers.

It falls back to sorting by highest score if no posts are trending.

Switch to Trending sort

Add ‘client_max_body_size xxM’ inside the http section in /etc/nginx/nginx.conf, where xx is the size (in megabytes) that you want to allow.

I had the same issue but in docker. when I faced this issue, added client_max_body_size 120M; to my Nginx server configuration,

nginx default configuration file path is /etc/nginx/conf.d/default.conf

after that, I did add these three lines to my PHP docker file

Ошибка 413 Request Entity Too Large — как исправить?

Данная ошибка больше интересует вебмастеров, т.к. связана напрямую с настройками сервера и nGinx. В статье исчерпывающая информация по данной ошибке с разбором действий по устранению ошибки 413. В каких случаях возникает ошибка 413? Как исправить ошибку 413 в сжатые сроки? Опыт вебмастеров, которые решили проблему.

Что такое ошибка HTTP 413?

Ошибка 413 — Request Entity Too Large говорит о том, что файл, который вы пытаетесь загрузить на сервер слишком большой для заданной конфигурации сервера. Обычно проблема возникает среди вебмастеров, которые создают свой первый сайт на базе CMS и при этом вообще не разбираются в коде. Как результат – не настроен сервер для обработки и загрузки изображений.

Обратите внимание, что в отличии от ошибки 409, здесь указана конкретная проблема. Здесь нет конфликта между настройками сервера. Нужно просто изменить переменные в настройках, если они доступны для вас в панели управления вашим хостинг аккаунтом.

Вебмастера могут столкнуться с ошибкой 413 Request Entity Too Large при использовании: NGINX, Apache, PHP. Чтобы устранить ошибку 413 нужно внести изменения в настройки, которые приведены ниже. Для этого вам понадобиться доступ к настройкам сервера или придется писать в поддержку хостинга, чтобы они внесли такие изменения (если вам не доступно).

По умолчанию, размер, который разрешен для загрузки – 1 мб. У меня на всех сайтах стоит 32 мб. Для пользователей размер установлен в рамках 4 мб., при этом в случае загрузки изображений на сайт, система автоматически их сжимает. Ниже представлены функции и их местонахождение.

Как исправить ошибку 413?

Если у вас NGINX

В дефолтных (стандартных) настройках стоит ограничение в 1 мб. За размер отвечает функция «client_max_body_size». Данная настройка указывает допустимый размер запроса в строке «Content-Length». В случае, когда размер больше 1 мб., возвращается ошибка 413 Request Entity Too Large.

Для решения ищем файл «nginx.conf», а в нем пункт http, где нужно добавит или изменить указанный выше размер функции. Исправляем ошибку 413 примерно вот так:

В данном случае – 64м, это уже измененный допустимый размер, который ранее был 1м. Слишком много не стоит устанавливать, если в этом нет нужды. Почему? Уже не первый раз замечаю, что при больших объемах затрачивается много оперативной памяти и процессорных минут, что может привести к «диалогу» с администрацией хостинга. После установки параметров не забудьте перезагрузить конфиг.

Если у вас PHP

Не всегда все упирается в настройки сервера, но и в настройки PHP. Вне зависимости от версии PHP для изменения допустимого размера загружаемых фалов через PHP скрипты нужно найти файл php.ini. Этот файл обычно находится в папке «etc». Открываем встроенным редактором (если есть) или текстовым редактором, вроде Notepad++. Ищем строки, которые указаны ниже:

И устанавливаем в этих строках нужные вам размеры. Например, 8М – это и есть 8 мб. Для скриптов крайне противопоказано устанавливать разрешения на загрузку больших файлов. Также не стоит разрешать загружать произвольные файлы. В случае, если сайтом заинтересован злоумышленник, он легко сможет залить файлы на сайт, которые вам не понравятся.

Если у вас Apache

В отличии от примеров выше, в Apache размер указывается в байтах. Файл для редактирования находится по следующему адресу: /etc/httpd/conf/httpd.conf или /etc/apache/apache.conf. В файле нужно найти и изменить пункт «LimitRequestBody. Ниже пример.

В данной строчке лимит, который вы задаете – 1048576 или 8 МБ. Никаких букв после цифр ставить не нужно.

Для пользователей

Если вы загружаете фотографию или аватарку на сайт и он выдает ошибку 413, вы решить этот вопрос не сможете, разве только уменьшив размер файла. Помните, что стандартный размер – 1 мб, а значит, если сайт не принимает ваше фото или файл, просто уменьшите его до 1 Мб.

How to avoid Request Entity Too Large 413 error

The requested resource /serverpath/reports.php does not allow request data with POST requests, or the amount of data provided in the request exceeds the capacity limit.

Apache Server at demo3.website_name Port 80

So, could any one please help to set php.ini and how to set htaccess to allow overwrite status

5 Answers 5

Trending sort

Trending sort is based off of the default sorting method — by highest score — but it boosts votes that have happened recently, helping to surface more up-to-date answers.

It falls back to sorting by highest score if no posts are trending.

Switch to Trending sort

How to fix it in NGINX? client_max_body_size

To fix this, you need to increase the value of the client_max_body_size directive. This directive defines the maximum amount of data Nginx will accept in an HTTP request. By default this value is set to 1 megabyte, meaning if you attempt to upload a file larger than 1 megabyte you’ll be getting an Error 413: Request entity too large page. You can insert this directive at three levels:

In the http block: this will set the directive value for all server and locations in your configurationn

In the server block: this will set the directive value for all locations of one particular server

In the location block: this will set the directive value for one specific location in a particular server

In this example I’m going to insert it in my http block and set it to 500 megabytes:

Описание ошибки

413 Request Entity Too Large

Данная ошибка может появиться в том случае, если вы загружаете какой-либо файл на сервер и размер этого файла превышает максимально разрешенный в конфиге в веб-сервера (например, в nginx по умолчанию установлено ограничение в 1 МБ). Для того, чтобы это исправить, необходимо внести определенные правки в файл конфигурации, который может быть разным, в зависимости от используемого веб-сервера. Ниже будут приведены примеры для самых популярных веб-серверов:

nginx

После изменения настроек нужно обязательно перезагрузить конфиг в nginx.

Apache

httpd.conf

Для применения настроек нужно перезагрузить веб-сервер Apache.

.htaccess

Если для работы сайта и заливки файла используется PHP, то нужно добавить еще другую строчку:

Если при заливке файла используется PHP скрипт, то для PHP имеются отдельные настройки максимального размера файла. Для их изменений потребуется внести правку в файл php.ini, который расположен по адресу /etc/ /fpm. Открываем его любым текстовым редактором и находим следующие строки:

И выставляем им нужные значения, например 4M (т. е. 4 МБ).

После внесения правок просто перезагружаем php, и проверяем работу.

Блог PQ Hosting

Что означает ошибка 413

Ошибка 413 или Request Entity Too Large расшифровывается как «объект запроса слишком велик» или простыми словами объем передаваемых данных слишком большой. Ошибка возвращается в случае, если сервер не может обработать запрос по причине слишком большого размера тела запроса (или большого файла). Снимок экрана с ошибкой изображен ниже:

Как исправить

Для исправления ошибки 413 следует увеличить допустимый лимит. Увеличить размер тела запроса и соответственно, загружаемых файлов, можно путем использования client_max_body_size. Опциюя доступна для использования в директивах http, server или location в конфигурационном файле /etc/nginx/nginx.conf или в конфигурационном файле веб-сайта.

Откройте конфигурационный файл nginx.conf при помощи любого текстового редактора:

Вписываем строчку в секцию http:

Когда ограничение на загрузку необходимо выставить только для конкретного раздела на сайте, строку client_max_body_size необходимо вписать в директиву location конфигурационного файла сайта, который по умолчанию находиться в /etc/nginx/sites-available/имя_файла_с_конфигурацией:

Как только были внесены изменения в конфигурационные файлы, сохраните их, закройте текстовый редактор и проверьте синтаксис конфигурационных файлов на наличие ошибок при помощи команды:

Вы можете увидеть следующие строки:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

В этой статье рассмотрена ошибка в Nginx, известная 413 Request Entity Too Large, возникающая при загрузке больших файлов на веб-сайт. Помимо описания самой ошибки также было описаны шаги по устранению ошибки путем редактирования конфигурационных файлов Nginx.

Разное → Боремся с ошибкой 413 Request Entity Too Large

Директива client_max_body_size задаёт максимально допустимый размер тела запроса клиента, указываемый в строке «Content-Length» в заголовке запроса. Если размер больше заданного, то клиенту возвращается ошибка «Request Entity Too Large» (413). Следует иметь в виду, что браузеры не умеют корректно показывать эту ошибку. Подробнее.

Решение

3. Перезагружаем nginx любой из четырёх команд:

если не нашли то причина скорей всего не в ней, потому что по умолчанию ограничения отсутствуют, хотя можете попробовать 🙂 если не поможет то придётся погуглить 😉

Этой строчки у меня в nginx 0.6.75 не было.
Добавил, перезапустил сервер, все нормально пошло, файлы грузятся больше 1 мб, а я блин голову с php.ini ломал 😉

а где находиться этот nginx. пожалуйста, опишите путь подробно. за ранее спасибо

HTTP Status Code for Larger Response 413 / 400

Part of Google Cloud Collective

I am getting below error when response is larger in size, We can fix below by enabling Streaming in Apigee ( Currently out of scope as needs work at all up streams)

413 Request Entity Too Large

400 «Message: Response is large»

5 Answers 5

Trending sort

Trending sort is based off of the default sorting method — by highest score — but it boosts votes that have happened recently, helping to surface more up-to-date answers.

It falls back to sorting by highest score if no posts are trending.

Switch to Trending sort

Well, it looks like it should be a 500 error. And, as a good practice, you should add some details in the body or a good and clear message, as said before by some wise people here.

All the 4xx errors indicates that the system is fine but your request is not. Some examples:

You can check all RFCs you want and will not find a 4xx error for this situation. Unless you misexplained and the user should change the request in any way in order to get the right result. In this case, 422 could be your choice, for example, if the request is in the right format and syntax, but the user is requesting too many resources.

When my system send a http request using okhttp3 the follow issue occurs: 413 Request Entity Too Large

I would to know how I set a maximum size in okhttp3 request or if there is another solution for this issue.

2 Answers 2

Trending sort

Trending sort is based off of the default sorting method — by highest score — but it boosts votes that have happened recently, helping to surface more up-to-date answers.

It falls back to sorting by highest score if no posts are trending.

Switch to Trending sort

This is not actually an issue with your code, rather the server you are sending the data to has a limitation on the request payload size. For more info about the error see: HTTP Response Status Code 413: Payload too large

If you are in control of the server you may adjust this setting. Examples for fixing this error for a couple of common servers (Apache, NGINX, IIS) may be found here.

If you are not in control, you may want to look at the API / documentation of the service you are using for other ways of uploading the data. The service might simply have strict limitations on payload size for that particular use-case.

waldemarnt/http-status-codes

Use Git or checkout with SVN using the web URL.

Work fast with our official CLI. Learn more.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching GitHub Desktop

If nothing happens, download GitHub Desktop and try again.

Launching Xcode

If nothing happens, download Xcode and try again.

Launching Visual Studio Code

Your codespace will open once ready.

There was a problem preparing your codespace, please try again.

Latest commit

Git stats

Files

Failed to load latest commit information.

README.md

Http Status Codes

Useful informations about each kind of http code

Inspired by the awesome lists

The list is separated by kind.

These codes indicate success. The body section if present is the object returned by the request. It is a MIME format object. It is in MIME format, and may only be in text/plain, text/html or one fo the formats specified as acceptable in the request.

The codes in this section indicate action to be taken (normally automatically) by the client in order to fulfill the request.

Client side errors 4xx

The 4xx codes are intended for cases in which the client seems to have erred, and the 5xx codes for the cases in which the server is aware that the server has erred. It is impossible to distinguish these cases in general, so the difference is only informational.

The body section may contain a document describing the error in human readable form. The document is in MIME format, and may only be in text/plain, text/html or one for the formats specified as acceptable in the request.

Server side error 5xx

This means that even though the request appeared to be valid something went wrong at the server level and it wasn’t able to return anything.

Contributions welcome! Read the contribution guidelines first.

Github Push Error: RPC failed; result=22, HTTP code = 413

stupid issue with Github going on right now. I have a decent amount of changes (

120MB in size), when I attempt to push, this is what happens:

I’ve already done

18 Answers 18

Trending sort

Trending sort is based off of the default sorting method — by highest score — but it boosts votes that have happened recently, helping to surface more up-to-date answers.

It falls back to sorting by highest score if no posts are trending.

Switch to Trending sort

If you get error 413, then the issue doesn’t lie with git but with your web server. It’s your web server that is blocking big upload files.

Solution for nginx

Just load your nginx.conf and add client_max_body_size 50m; ( changing the value to your needs ) in the http block.

Reload nginx to accept the new config by executing sudo service nginx reload and try again to push your commit over http.

3 Answers 3

Trending sort

Trending sort is based off of the default sorting method — by highest score — but it boosts votes that have happened recently, helping to surface more up-to-date answers.

It falls back to sorting by highest score if no posts are trending.

Switch to Trending sort

I created an asp.net mvc application and tried to test it.

Often we only pay attention to the uploadReadAheadSize setting, but tests have proved that this cannot completely solve the problem, and there are other configurations that need to be configured. (Added based on Jack’s answer)

In addition to setting the uploadReadAheadSize value larger, there are also maxAllowedContentLength and maxRequestLength. You need to modify all these three values, otherwise the 413 or Maximum request length exceeded error will still be displayed.

In my test results, the application can upload any type of file within 1GB.

Here is my cheat sheet:

The max file size limit coming through from IIS is specified through the UploadReadAhaead parameter, which can be specified in web.config as so. In this case, the maximum is set to 1000485760 bytes

This is grand, as long as this specifier actually works. You might need a different solution, say, if you are hosting locally with something other than IIS (like kestrel, or even IIS express.)

Sometimes this configuration section is locked as well, in which case it can be unlocked using the following command (run cmd as admin):

This is also something to consider when setting up prod. In some cases, your configuration within web.config within your code for the uploadReadAheadSize can conflict with whatever is specified in your prod instance. For me, I ended up getting rid of my configuration within source control, and instead, set the uploadReadAhead value for prod during environment set up. I did this by running the command (in cmd as admin):

I also set uploadReadAheadSize within C:\inetpub\wwwroot\web.config on the prod server as well, so it looks something like:

This can also be set as per this screenshot:

[![enter image description here][1]][1]

Как исправить ошибку HTTP 413 (Request Entity Too Long)

	Номер ошибки:	Ошибка HTTP 413
	Название ошибки:	Request Entity Too Long
	Описание ошибки:	The requested file was too large to process.
	Разработчик:	Microsoft Corporation
	Программное обеспечение:	Windows Operating System
	Относится к:	Windows XP, Vista, 7, 8, 10, 11

Распространенные сообщения об ошибках в Request Entity Too Long

Проблемы с Request Entity Too Long возникают во время запуска или завершения работы, во время запуска программы, связанной с Request Entity Too Long, или иногда во время обновления или установки Windows. Выделение при возникновении ошибок Request Entity Too Long имеет первостепенное значение для поиска причины проблем Edge и сообщения о них вMicrosoft Corporation за помощью.

Источник ошибок Request Entity Too Long

Проблемы Request Entity Too Long могут быть отнесены к поврежденным или отсутствующим файлам, содержащим ошибки записям реестра, связанным с Request Entity Too Long, или к вирусам / вредоносному ПО.

В частности, проблемы Request Entity Too Long, созданные:

Совместима с Windows 2000, XP, Vista, 7, 8, 10 и 11

Error : Failed to load resource: the server responded with a status of 413 (Request Entity Too Large) [duplicate]

I’m getting the following error.

Failed to load resource: the server responded with a status of 413 (Request Entity Too Large)

What should I do?

1 Answer 1

A 413 Request Entity Too Large error occurs when a request made from a client is too large to be processed by the webserver. If your web server is setting a particular HTTP request size limit, clients may come across a 413 Request Entity Too Large response. An example request, that may cause this error would be if a client was trying to upload a large file to the server (e.g. a large media file).

See this thread and configure your webserver to change the allowed upload limit.

How to Fix 413 Request Entity too Large Error in WordPress

Ever tried uploading a file to WordPress only to see the 413 Request Entity Too Large error pop up? Annoying, right? Well don’t worry, we have a solution! In this article, we will teach you how to fix the 413 Request Entity Too Large error in WordPress.

Error code	413 Request Entity Too Large
Error type	Client-side
Error variations	413 Payload Too Large HTTP Status Code 413
Error causes	Request too large PHP limits too low The page was not displayed because the request entity is too large.

What Does 413 Request Entity Too Large Error Mean?

The 413 Request Entity Too Large error means that the client’s request is too large to be processed by the server. The 413 error commonly occurs when uploading a file larger than the set server limit.

Hosting providers tend to have specific configurations on their server for uploading media to WordPress, and in most cases, these default settings provide sufficient resources for your posts and uploads.

However, in certain cases, you might need to upload a file that exceeds the size limit, and you will unfortunately face the 413 error.

How to Fix 413 Request Entity Too Large Error in WordPress

Luckily, there are a few ways to fix this issue. We will teach you three different methods of how to deal with the error 413 on WordPress.

Important! Two of the methods deal with important WordPress files, so we strongly suggest you back up your files before starting any configuration.

1. Modifying the functions.php file

You can find the functions.php file in your WordPress themes folder. This file is often used to define ‘classes’ and ‘actions’ on your WordPress site. It can add features and functionality like enabling post thumbnails, post formats, and navigation menus.

To modify functions.php access your Hostinger Control Panel. Then, go to the File Manager under the Files section.

In the Hostinger File Manager, you will see three folders under the public_html folder. Click on the wp-content folder that will give you a list of files on the right side. Double click on themes folder to find the functions.php file. Make sure you choose the file of the theme you are currently using.

Double click the functions.php file and add the following code snippet. It will increase It will increase upload_max_size, post_max_size and max_execution_time values.

After you are finished, save the changes and try head back to WordPress admin area to test if you still get HTTP 413 error.

The second method involves editing the .htaccess file, so be cautious not to make any unnecessary changes.

The .htaccess file is a configuration item which is read by the server. It can override server configuration settings for things like authorization, caching, or even optimization.

To reach the .htaccess file, you need to go to your public_html folder in your Hostinger control panel. On the right side, you will see the .htaccess file. Double click on it.

You will get a popup window where you can add in the code. Read through the lines, when you find # END WordPress at the end of the file, paste in the following code under it:

Make sure you save the modification and close the window. Go back to WordPress admin area and try upload a new.

3. Modifying Nginx Configuration

If you use a Hostinger VPS, you’ll get control over most of your server environment. We only reach basic server software (Apache or Nginx) in its default state. That means if you want to tweak more, you are free to revise it.

When the web server is set to restrict large file sizes, it can cause the 413 error request entity too large. Nginx has client_max_body_size to allow the maximum size of the client request body. If the request exceeds the value, an error message emerges. That means we need to reconfigure Nginx to allow the size we want for uploading files.

Reconfiguring nginx.conf will require a text editor. We recommend Vi text editor as it will handle the job perfectly.

Access your VPS via ssh and type the following command on your terminal to start editing with Vi:

After that, you can add the following lines in nginx.conf as shown in the example below. It sets the maximum body size of a client request that the server allows. So, make sure you put the right number as your maximum size.

Save and close the file. Then, you can reload the Nginx web server with this following command:

Now you can go ahead and check if the error 413 is gone.

Troubleshooting Other 4xx Errors

Conclusion

If you want to upload a file larger than allowed by your server, you will face the 413 Request Entity Too Large error in WordPress. In this tutorial we overviewed 3 different methods to fix 413 error.

Support

Find answers, guides, and tutorials to supercharge your content delivery.

Fixing 413 Request Entity Too Large Errors

The 413 Request Entity Too Large error already gives a hint in its name about what the solution to the problem could be. It’s literally a size problem.

This article will go through step-by-step how you can fix the 413 Request Entity Too Large error. As with all error messages, there are more or less elaborate measures you can take to get to the problem’s solution. We’ll show you how to make the process of fixing the error as simple as possible.

What does 413 Request Entity Too Large mean?

A 413 Request Entity Too Large error occurs when a request made from a client is too large to be processed by the web server. If your web server sets a specific HTTP request size limit, clients may come across a 413 Request Entity Too Large response. An example request that may cause this error would be if a client was trying to upload a large file to the server (e.g., a large media file).

Meanwhile, the error is also known as the 413 Payload Too Large error. The name has been changed to be more clear and more specific. Nevertheless, you will see the old name much more often in practice.

But why does this error occur at all? The simplest explanation is that the server is set to explicitly deny too large uploads.

It depends on the type of web server you are using, which will determine which directive you need to configure. Whether you want to restrict users from uploading overly large files to your web server or want to increase the upload size limit, the following section will explain how.

Fixing 413 Request Entity Too Large errors

Fixing this error is about increasing the maximum file size for the server in question. Once that is done, the error should no longer occur.

Depending on which web server you use, implement the necessary changes described below to configure your web server’s maximum HTTP request size allowance. You can set the threshold file size for which a client is allowed to upload, and if that limit is passed, they will receive a 413 Request Entity Too Large status.

The troubleshooting methods require changes to your server files. For this reason, we recommend that you create a backup before performing the following steps.

Nginx

Apache

For example, if you wanted to restrict requests larger than 100 MB, you would use the following.

In addition to modifying the appropriate directive on your web server, several other changes are required for PHP users. First, you need to open up your php.ini file, which will most likely be located in a directory similar to /etc/php8/fpm/php.ini (depending on your PHP version). Next, you’ll need to find and modify the following directives:

How to Fix the «DNS Server Not Responding» Error

One of the most common errors that Windows and Mac users will see when trying to access a website is «DNS Server Not Responding.» This problem can occur for many reasons, but the good news is that you can take steps to fix it. ConsideringвЂ¦

How to Fix the ERR_CONNECTION_REFUSED Error (Chrome)

If you frequently use the Internet, chances are you have encountered the ERR_CONNECTION_REFUSED error. It is one of the most common and persistent errors that Chrome users encounter. It can be caused by numerous issues and could even be a sign thatвЂ¦

413 Request Entity Too Large nginx django

I am making a practice web service (client’s artbook display web site) The client can upload artbook images to the server.

But I get the following error when the client uploads too many images

I tried adding client_max_body_size 100M; in nginx.conf

Can anybody help?

3 Answers 3

Trending sort

Trending sort is based off of the default sorting method — by highest score — but it boosts votes that have happened recently, helping to surface more up-to-date answers.

It falls back to sorting by highest score if no posts are trending.

Switch to Trending sort

You’ve fixed the issue on your HTTP server, but your HTTP server is set to 301 redirect to your HTTPS server. your HTTPS server does not have client_max_body_size configured, so it is defaulting to 1M & causing this 413 (Request Entity Too Large) error.

To fix this issue, you simply need to add client_max_body_size to BOTH the HTTP server block and the HTTPS server block, as shown in the example below:

Syntax: client_max_body_size size;

Default: client_max_body_size 1m;

Context: http, server, location

Sets the maximum allowed size of the client request body, specified in the “Content-Length” request header field. If the size in a request exceeds the configured value, the 413 (Request Entity Too Large) error is returned to the client. Please be aware that browsers cannot correctly display this error. Setting size to 0 disables checking of client request body size.

Error when uploading sourcemaps to Sentry (Error 413, request entity too large) #326

Comments

SanderVerkuil commented Jan 10, 2018 •

I have following issue:

The build fails for production when uploading the sourcemaps:

Steps to reproduce:

Actual result:

Expected result:

What is the maximal filesize of the sourcemaps?

The text was updated successfully, but these errors were encountered:

HazAT commented Jan 31, 2018

Hey, sorry for the late reply.
Currently, there is a limit in Sentry when uploading large artifacts.
We are working to fix this since it is not 100% deterministic when a request is too large.
getsentry/sentry#7095

Please be patient and bare with us 🍪

dmitrika commented Feb 6, 2018 •

@HazAT Did I get it right, now we have to uninstall rn-sentry to be able to build an android app?

SanderVerkuil commented Feb 6, 2018 •

@dmitrika as far as I could tell removing the upload gradle task from the android/app/build.gradle should do the trick. You just don’t have the codemaps on sentry.

lig commented Mar 2, 2018

@HazAT Hello! I see several PRs merged in context of this one. Is there any roadmap for everything related? It will be handy to be able to keep track of this. Thank you!

se-bastiaan commented Aug 11, 2018 •

So I tried to understand the work done on chunk uploading. Maybe even fix this. These are my notes in that process.

sentry-cli has code for uploading chunks and assembling them:
upload chunks
assemble chunks

However, the SourceMapProcessor used in the react-native x (x in [gradle, xcode, appcenter, codepush]) doesn’t use the chunk upload (yet?). It’s only used in the upload_dif command.

I don’t think I completely grasp everything, but what I suspect that the current chunk upload was especially made for dsyms (and related difs) and not for the JS sourcemaps since those use the release file upload.

HazAT commented Aug 13, 2018

@se-bastiaan You are right! We still want to support chunk upload for source maps though. I can’t give you an exact timeframe when this will happen but I have something other in mind.
We will soon ship (1-2 weeks) gzip compression for uploads with Sentry CLI, this should at least buy us some time until we hit the cap again.
Will comment here again when everything is in production.

lizraeli commented Aug 13, 2018

@SanderVerkuil sorry for the noob question: what exactly do you mean by

I’m running into a 413 issue while trying to send data from my web application (.netfx 4.6.1) to my web api (.net core 3.1). In the code below, I send a list over containing byte data of images along with additional data needed to build a file. The expected output is to return a byte array containing the new file. Unfortunately when sending the request I receive an error: Response status code does not indicate success: 413 (Request Entity Too Large).

The error only seems to occur when the file is large to begin with, which makes sense. The research I’ve done seems to point to settings in IIS, the main ones being maxAllowedContentLength, maxRequestLength, and uploadReadAheadSize. I’ve tried increasing these values to ones more suited to this process but nothing seems to work. I’ve adjusted them for both the web application and the web api, as I was not sure which one was causing the problem.

Where does the problem lie? In the application, the API, or both? Is there an additional setting I’m missing to allow an increased size? Is there an issue with how I’m sending the request? Any help is appreciated.

Как исправить код веб-ошибки Ошибка 413 Запрос объекта слишком длинный

В этой статье представлен номер ошибки Ошибка 413, широко известный как Запрос объекта слишком длинный, описанный как Запрошенный файл слишком велик для обработки.

Информация об ошибке

Имя ошибки: Запрос объекта слишком длинный
Номер ошибки: Ошибка 413
Применимо к: Windows 10, 8, 7, Vista, XP
Описание: Запрошенный файл слишком велик для обработки.

Это средство исправления может устранить такие распространенные компьютерные ошибки, как BSODs, замораживание системы и сбои. Он может заменить отсутствующие файлы операционной системы и библиотеки DLL, удалить вредоносное ПО и устранить вызванные им повреждения, а также оптимизировать ваш компьютер для максимальной производительности.

О кодах состояния

Когда вы получаете коды веб-ошибок, у вас могут быть проблемы либо с клиентом, либо с сервером. Проблема может быть связана с браузером или настройками, которые блокируют ваше соединение, или это могут быть любые другие проблемы, связанные с сервером, к которому вы пытаетесь получить доступ.

Чтобы объяснить проблему подробнее, вот несколько полезных сведений о кодах веб-ошибок, их симптомах, причинах и методах устранения.

Определения (Бета)

Здесь мы приводим некоторые определения слов, содержащихся в вашей ошибке, в попытке помочь вам понять вашу проблему. Эта работа продолжается, поэтому иногда мы можем неправильно определить слово, так что не стесняйтесь пропустить этот раздел!

Коды веб-ошибок также известны как коды состояния http. Существует пять различных классов кодов состояния http, и они всегда начинаются со следующих цифр, в зависимости от того, с какой ошибкой столкнулся пользователь. Это также симптомы ошибки, с которой столкнулся пользователь. Для дальнейшего объяснения ниже приведены коды состояния.

(Только для примера)

Коды 4XX возникают по вине пользователя или настроек со стороны пользователя. Запрос не был понят сервером из-за неправильного ввода адресной строки, неправильного синтаксиса, нестабильного соединения или ошибочной ОС.

Методы устранения

Для определенных кодов веб-ошибок существуют конкретные шаги по устранению неполадок. Однако существуют и обобщенные методы устранения, которые пользователи могут применять при возникновении подобных ошибок.

Если метод ремонта вам подошел, пожалуйста, нажмите кнопку upvote слева от ответа, это позволит другим пользователям узнать, какой метод ремонта на данный момент работает лучше всего.

How to Solve the “413 Request Entity Too Large” Error for Your WordPress Website

WordPress errors come in all shapes and sizes. In most cases they’re easy to decipher; such is the accessibility of WordPress’ error reporting. Even so, when the “413 Request Entity Too Large” error pops up, it can leave you scratching your head.

Without realizing it, you already have everything you need to understand and diagnose the error within its name. The good news is you won’t need more than a standard Secure File Transfer Protocol (SFTP) client and administrator access to your server.

In this post, we’ll take a look at how to solve the “413 Request Entity Too Large” error. We’ll also give you a quick list of steps to take before you begin to solve the error, to make the process super straightforward.

Check out our video guide to fixing the “413 Request Entity Too Large” Error

What the “413 Request Entity Too Large” Error Is (And Why It Exists)

We noted that there’s a clue in the error name as to what the solution and problem are. Before you go sleuthing yourself, though, we’ll spoil the surprise: it’s in the adjective “large.”

Kinsta spoiled me so bad that I demand that level of service from every provider now. We also try to be at that level with our SaaS tool support.

Suganthan Mohanadasan from @Suganthanmn

In a nutshell, the “413 Request Entity Too Large” error is a size issue. It happens when a client makes a request that’s too large for the end server to process. Depending on the nature of the error, the server could close the connection altogether to prevent further requests being made.

Let’s break the error down into its parts:

In fact, this error has changed its name from what it originally was to be more specific and offer more clarity. It’s now known as the “413 Payload Too Large” error, although in practice, you’ll see the older name a lot more.

As for why the error occurs, the simple explanation is that the server is set up to deny explicit uploads that are too large. Think of times when you upload a file where there’s a maximum file size limit:

The TinyPNG home page.

In most cases, there will be some validation in place to stop the error… if you’re seeing the “413 Request Entity Too Large” error, those validation efforts may not be as watertight as you think.

What You’ll Need to Resolve the “413 Request Entity Too Large” Error

Fixing this error is all about raising the maximum file size for the server in question. Once that’s out of the way, you shouldn’t see the error anymore.

As such, to fix the “413 Request Entity Too Large” error, you’ll need the following:

As an aside, we mention SFTP throughout this article as opposed to FTP. In short, the former is more secure than the latter (hence the name). That said, while there are other differences you should investigate, the functionality remains the same for the vast majority of uses.

Also, it’s worth noting that the MyKinsta dashboard has plenty of functionality on hand to help you get onto your server. For example, each site displays SFTP connection information that’s easy to understand:

The SFTP panel in the MyKinsta dashboard.

This can help you get into your site without fuss. In some cases, you may be able to import the credentials straight to your chosen SFTP client.

3 “Pre-Steps” You Can Take Before Rectifying the “413 Request Entity Too Large” Error

Before you crack open your toolbox, there are some steps you can take to help resolve the “413 Request Entity Too Large” error. Here are two — and each one may give you a welcome workaround to the error.

1. Try to Upload a Large File to Your Server Through SFTP

Because the issue is related to the file sizes hitting your server, it’s a good idea to circumvent the frontend interface and upload a large file to the server yourself. The best way to do this is through SFTP.

This is because protocols such as SFTP are almost as “close to the bone” as you can get with regards to the way you access your server. Also, you can simultaneously rule out any issues with the frontend that may be causing the error.

To do this, log into your site through SFTP and find the wp-content folder. In here will be the uploads folder.

The uploads folder seen from an SFTP client.

Next, upload your file to this folder on the server and see what the outcome is. If the upload is successful, we suggest sending an email to the site’s developer, as they may want to investigate the issue further on the frontend.

2. Check for Server Permissions Errors

Of course, permissions errors will stop any server request from running. As such, you should check whether the user has sufficient permissions to upload files of any size. Once this is sorted, the error should disappear.

The first step is to determine whether this is an issue with a single user (in which case they may be restricted for a reason). If the “413 Request Entity Too Large” error is happening for multiple users, you can be more sure of something that needs your input.

We’d suggest two “pre-fixes” here:

While they may not solve the error in the first instance, you’ll at least know that your file and user structure is as it should be.

How to Solve the “413 Request Entity Too Large Error” for Your WordPress Website (3 Ways)

Once you’ve gone through the pre-steps, you’re ready to tackle the error head-on.

The following three methods are listed from easiest to toughest, with the understanding that that the path of least resistance is the best one to take.

1. Edit Your WordPress functions.php File

First off, you can work with your functions.php file to help bump up the file upload size for your site. To do this, first log into your site through SFTP using the credentials found within your hosting control panel.

When you’re in, you’ll want to look for the file itself. The functions.php file should be in the root of your server. In many cases, this root is called www or public_html, or it could be the abbreviated name of your site.

Once you’ve found it, you can open it in your text editor of choice. If you don’t see the file, you can create it using your text editor.

Once you have a file open, enter the following:

In short, this increases the maximum file size of posts and uploads while boosting the time the server will spend trying to process the request. The numbers here could be anything you wish, but they should be large enough to make the error disappear. In practice, 64 MB is enough for all but the most heavy-duty of tasks.

The functions.php file.

When you’re ready, save your file and upload it to the server again. Then, check whether the “413 Request Entity Too Large” error still exists. If it does, head onto the next method.

Much like your functions.php file, your .htaccess file sits on your server. The difference here is that .htaccess is a configuration file for Apache servers. If you’re a Kinsta customer, you’ll know we run Nginx servers, so you won’t see this file in your setup.

Still, for those with an Apache server, this is the approach you’ll need. Much like with the guidance for functions.php, first log into your server through SFTP, then look in your root folder as before.

The .htaccess file should be within this directory, but if it’s missing, we suggest you get in touch with your host to determine where it is, and whether your server runs on Nginx instead.

In short, this does almost the same thing as the code you’d add to the functions.php file, but it’s akin to giving the server direct instructions.

When you’ve finished, save your changes, upload the file, and check your site again. If you’re still having trouble, we’d again suggest contacting your host, as they will need to verify some aspects of your setup that lie beyond the scope of this article.

3. Change Your Nginx Server Configuration

Our final method is specific to Nginx servers — those used at Kinsta. The purpose is the same as when working with the .htaccess file, in that you’re talking to the server, rather than going through WordPress.

We mentioned that for Apache servers you’ll use .htaccess. For Nginx servers, though, you’ll want to find the nginx.conf file. Rather than walk you through every step in the chain, we’ve gone over the full details in our post on changing the WordPress maximum upload size.

Remember that you’ll need to also alter the php.ini file based on the changes you make to nginx.conf. We’ve covered that in the aforementioned blog post too, so take a look there for the exact steps.

Summary

Despite WordPress being a rock-solid platform, you’ll see a lot of different WordPress errors over time. The “413 Request Entity Too Large” error is related to your server, though — not WordPress. As such, there’s a different approach to solving this error than other platform-specific issues.

If you have SFTP skills, there’s no reason you can’t fix this error quickly. It relates to the upload size specified in your server configuration files, so digging into your .htaccess or nginx.config files will be necessary. It’s a breeze to crack open your text editor and make the changes to these files, and if you’re a Kinsta customer, we’re on hand to support you through the process.

Save time, costs and maximize site performance with:

All of that and much more, in one plan with no long-term contracts, assisted migrations, and a 30-day-money-back-guarantee. Check out our plans or talk to sales to find the plan that’s right for you.

Устранение ошибки «413 Request Entity Too Large Error» на Nginx / Apache

Это часто происходит, когда запрос, сделанный клиентом, слишком велик и не может быть обработан веб-сервером.

Измените максимальные значения загрузки PHP

Откройте файл конфигурации PHP. например, /etc/php.ini и изменить максимальные пределы загрузки для файлов.

Вы также можете настроить максимальное время выполнения и ограничение памяти для скриптов PHP.

Установить размер body клиента – Nginx

Откройте файл конфигурации Nginx.

Это может быть глобальный файл nginx.conf или файл конфигурации сайта.

Установите размер тела клиента.

Затем перезапустите nginx и php-fpm – команды перезапуска могут отличаться.

Установите директиву LimitRequestBody – Apache

Если ваш веб-сервер Apache, установите директиву LimitRequestBody.

Используйте калькулятор Megabytes to Bytes, чтобы получить нужные значения.

Перезапустите веб-сервер Apache, когда закончите

Теперь вы решили ошибку «413 Request Entity Too Large Error».

Попробуйте снова загрузить файл, и попытка должна быть успешной.

maxReceivedMessageSize not fixing 413: Request Entity Too Large

My call to my WCF web service is failing with System.Net.WebException: The request failed with HTTP status 413: Request Entity Too Large.

Checking Fiddler, I see that I’m sending:

Which is over 65KB.

Enabling WCF tracing on the server, I see:

System.ServiceModel.ProtocolException: The maximum message size quota for incoming messages (65536) has been exceeded. To increase the quota, use the MaxReceivedMessageSize property on the appropriate binding element.

Adding this property doesn’t solve the issue.

I’ve tried with just that property, and (later) with various others that posts have suggested. Here’s what I have currently (on the server):

My sole endpoint (under ) is:

I’ve even run (for IIS 7):

Nothing makes any difference.

One catch is that this is a WCF service meant to replace an older ASMX service. The service skeleton was generated with svcutil from existing WSDL. I can’t change the client configurations (and the clients are in multiple languages). My test client project imported the service with Add Web Reference (under Add Service Reference / Advanced ), so I have no WCF configuration. However, the test client works if I point it at the older ASMX service.

Request failed with status code 413

Вопрос

I have SCCM fully updated, and it’s been handling updates for quite some time without issues. Recently, I’ve been seeing a lot of 413 errors in the Windows Update log during the scan. They look like this:

I started digging because certain clients were not receiving updates. I believe the clients may be having difficulty scanning against the WSUS server. If I scan against Windows Update, I can see updates are available and I don’t see these errors. It’s only when I use SCCM client and run a software updates scan.

I can’t find any information on WSUS and HTTP 413 errors. Has anyone ever seen this? Any tips would be greatly appreciated!

Here is a larger clip of the log.

Ответы

I think this error isn’t important though. The problem that led me to this error was that no updates were showing up when I scanned against WSUS. If I scanned against Microsoft, I would see a dozen updates available.

I may have uncovered another problem completely unrelated to this error. I use sccm to deploy updates, and I have a powershell script that creates my deployments as I need 8 of them for every SUG I deploy. This script creates the deployment and sets it the available and required dates a few weeks out.

At this time, I think I’m all set. I was apparently looking for assistance on a problem that wasn’t a problem! I appreciate the help!

HTTP Error 413 Request Entity Too Large #537

Comments

jrobertsvml commented Feb 9, 2015

Any way to fix this?

Error: [Guzzle\Http\Exception\ClientErrorResponseException] Client error response
[status code] 413
[reason phrase] Request Entity Too Large
[url] https://dns.api.rackspacecloud.com/v1.0/432716/domains/3903288

The text was updated successfully, but these errors were encountered:

jamiehannaford commented Feb 10, 2015

@jrobertsvml Hi Joseph, can you paste some of the code you’re using which results in the 413 error?

jrobertsvml commented Feb 10, 2015

This line is where the stack trace begins:

jamiehannaford commented Feb 10, 2015

@jrobertsvml In order to debug further, could you follow a few steps:

jamiehannaford commented Feb 10, 2015

@jrobertsvml So it looks like you’re exceeding your HTTP requests quota. The API is basically saying that you’re hitting it too many times per minute. If you look at the docs, it says that for GET requests on domain resources, the limit is 60 per minute. If you exceed that, a 413 error will be returned. Here are some ideas that might get around this problem:

I hope this helps, and sorry for your inconvenience. If there’s anything else I can help with, feel free to comment here.

jrobertsvml commented Feb 10, 2015

I appreciate you looking into the issue and identifying the problem. I’m thinking about refactoring, but is there a way to grab all of the dns entries and their child records all at once?

jamiehannaford commented Feb 10, 2015

You can grab up to 100 domains per request, so it depends on the total size of your domain collection.

In terms of the child records, you will unfortunately need to execute at least 1 request per domain. This is because a record is associated with a domain in a REST hierarchy, so there is no current way to do a global search 😞 Sorry I can’t be of more help. If you need any functionality added or altered to the SDK that you think might benefit you and other users, please contact me and I’ll see if I can help.

jrobertsvml commented Feb 10, 2015

I’d love to have an API call that returns json containing of all my domains and domain records. I can parse that on my end and only hit the API once.

jamiehannaford commented Feb 11, 2015

jamiehannaford commented Feb 12, 2015

@jrobertsvml Is there anything else you need help with? Otherwise, feel free to close this issue 🙂

Footer

You can’t perform that action at this time.

You signed in with another tab or window. Reload to refresh your session. You signed out in another tab or window. Reload to refresh your session.

413 PayloadTooLargeError: request entity too large #1824

Comments

Strandedpirate commented Dec 13, 2017

I need help configuring NGINX to allow large entities. We are using SSL with a certificate and everything works fine until we try to send anything greater than 1mb.

NGINX Ingress controller version:
quay.io/kubernetes-ingress-controller/nginx-ingress-controller:0.9.0-beta.19

Environment:
Azure
Kuberenetes
SSL enabled

What happened:
When PUTing to a service endpoint I recieve the error «PayloadTooLargeError: request entity too large» with code 413. It appears this is coming from this nginx controller.

What you expected to happen:
Not to see the error «PayloadTooLargeError: request entity too large»

How to reproduce it (as minimally and precisely as possible):
Our annotations on the nginx controller and the ingress:

nginx.conf after deployment

The text was updated successfully, but these errors were encountered:

cloudfront responds with a status of 413 (Request Entity Too Large)

Bad request. Generated by cloudfront (CloudFront) Request ID: I2fOApzZr4psKrWsY6abezp5R0m30zKDKE7c0MuB_JkjWbvxz5GVnQ==

Failed to load resource: the server responded with a status of 413 (Request Entity Too Large)

Is there any settings in cloud front which can allow to accept large URL request.

I know on apache that there are settings like LimitRequestBody which can allow large inputs, but request is not reaching to apache and error out by cloudfront itself.

1 Answer 1

This isn’t supported. CloudFront has these hard limits, which are reasonable for most applications:

Maximum length of a request, including headers and query strings: 20,480 bytes

Maximum length of a URL: 8,192 bytes

The apparent discrepancy between 8,226 − 8,192 = 34 is probably attributable to the length of your hostname and http:// if you’re counting that. CloudFront’s documentation says «URL» but the limit may actually only apply to the combined length of path + query-string, since the Host: header is separate from the rest of the request, in the actual HTTP protocol.

The limits mentioned above, and some others, do not appear to be negotiable.

Other limits, such as bandwidth (40 Gbps), number of web distributions per AWS account (200) are merely default limits, which you can potentially have increased by submitting a request to AWS support describing your use case, but that does not appear to be the case, here.

Angular can’t call api directly because of some authentication issues.

This sort of sounds like a case for ajax calls to a proxy REST API that fetches the data from the source requiring authorization, so the browser side code doesn’t have to. maybe something in Lambda behind API Gateway.

error: RPC failed; result=22, HTTP code = 413 #461

Comments

gitblit commented Aug 12, 2015

Originally reported on Google Code with ID 165

Reported by haseeb.yousaf@pentaloop.com on 2012-11-16 10:30:05

The text was updated successfully, but these errors were encountered:

gitblit commented Aug 12, 2015

Reported by James.Moger on 2012-11-16 13:01:16

gitblit commented Aug 12, 2015

Reported by haseeb.yousaf@pentaloop.com on 2012-11-16 13:23:08

gitblit commented Aug 12, 2015

Reported by James.Moger on 2012-11-16 19:21:24

gitblit commented Aug 12, 2015

Reported by James.Moger on 2012-11-16 19:22:45

gitblit commented Aug 12, 2015

Reported by haseeb.yousaf@pentaloop.com on 2012-11-17 07:13:31

gitblit commented Aug 12, 2015

Reported by haseeb.yousaf@pentaloop.com on 2012-11-17 07:24:18

gitblit commented Aug 12, 2015

Reported by James.Moger on 2012-11-17 14:11:18

— _Attachment: capture000.png
![capture000.png](https://storage.googleapis.com/google-code-attachments/gitblit/issue-165/comment-7/capture000.png)_

gitblit commented Aug 12, 2015

Reported by James.Moger on 2013-07-17 20:07:02

gitblit commented Aug 12, 2015

Reported by sudheer.cyberdyne on 2013-11-06 01:50:05

gitblit commented Aug 12, 2015

Reported by James.Moger on 2013-11-06 12:39:16

gitblit commented Aug 12, 2015

Reported by sundayfunday1234@outlook.com on 2013-11-12 15:46:40

milosmns commented Mar 11, 2017

I’ll write this comment on as many places as possible, I’ve just lost an hour trying to figure out what is happening. Even though it might not be related to the stuff you discussed, I’m pretty sure that people stumble upon this link as much as I do, so hopefully some of them will get the solution.

Switching to SSH

Note that # is the comment delimiter and you don’t have to write it.
This forces the push URL to use the SSH protocol.
3. Save but don’t close

Still having issues? Yeah, that’s because you need a proper SSH certificate (i.e. either generate a new public/private key pair or use the existing ones). That’s easy to find on Google, look for «Generate SSH key».

Configuring Git to use SSH

Now you have the two keys (private & public). Here is what I did to get them correctly configured with my Git client.

Add your SSH key so that Git can use it later:
ssh-add your_key_name_here
The output for that will be something like

Okay! Last step, finally.
git push
And your output should be something like this (push does not fail):

Hope this helps.

Error: request entity too large

I’m receiving the following error with express:

I am using meanstack. I have the following use statements in my express.js

Within fiddler I can see the content-length header with a value of: 1078702

I believe this is in octets, this is 1.0787 megabytes.

I have no idea why express is not letting me post the json array I was posting previously in another express project that was not using the mean stack project structure.

30 Answers 30

Trending sort

Trending sort is based off of the default sorting method — by highest score — but it boosts votes that have happened recently, helping to surface more up-to-date answers.

It falls back to sorting by highest score if no posts are trending.

Switch to Trending sort

I had the same error recently, and all the solutions I’ve found did not work.

After some digging, I found that setting app.use(express.bodyParser()); did set the limit correctly.

When adding a console.log(‘Limit file size: ‘+limit); in node_modules/express/node_modules/connect/lib/middleware/json.js:46 and restarting node, I get this output in the console:

Then I added console.log(‘Limit file size: ‘+limit); in node_modules/express/node_modules/connect/node_modules/raw-body/index.js:10 and saw another line in the console when calling the route with a big request (before the error output) :

This means that somehow, somewhere, connect resets the limit parameter and ignores what we specified. I tried specifying the bodyParser parameters in the route definition individually, but no luck either.

While I did not find any proper way to set it permanently, you can «patch» it in the module directly. If you are using Express 3.4.4, add this at line 46 of node_modules/express/node_modules/connect/lib/middleware/json.js :

The line number might differ if you don’t run the same version of Express. Please note that this is bad practice and it will be overwritten if you update your module.

So this temporary solution works for now, but as soon as a solution is found (or the module fixed, in case it’s a module problem) you should update your code accordingly.

I have opened an issue on their GitHub about this problem.

That said, the bodyParser() method will be deprecated in Connect 3.0 and should not be used. Instead, you should declare your parsers explicitly, like so :

In case you need multipart (for file uploads) see this post.

[second edit]

[third edit]

It seems that in Express v4.16.0 onwards, we can go back to the initial way of doing this (thanks to @GBMan for the tip):

Как исправить ошибку «413 Request Entity Too Large»

Ошибка nginx «413 Request Entity Too Large» может возникать при отправке серверу запросов большого объёма (загрузке файлов, к примеру). Причина ошибки может быть в двух местах.

Первое — в конфигурационном файле nginx указано слишком маленькое значение переменой client_max_body_size.

Второе (более редкое)- в конфигурационном файле apache установлено слишком маленькое значение LimitRequestBody.

Как исправить. Nginx

Для устранения ошибки откройте файл конфигурации nginx (как правило это /etc/nginx/nginx.conf) и в секции http добавьте строку (если такая уже есть — просто замените):

где, 200M — максимальный объём запроса (файла). В данном случае — 200 мегабайт. Приставка M — мегабайты, G — гигабайты. в результате должно получиться в конфиге что-то вроде:

Request not being denied with 413 status code

There is a need to deny requests that have ANY body contents (meaning that body size is > 0). I tried using RequestSizeLimit attribute but it does not seems to be working properly.

I am using Postman for tests. Provide «qwerty» as a value for body of POST request. Here is what Kestrel log looks like:

info: Microsoft.AspNetCore.Server.Kestrel[17] Connection id «0HLN06I1687S4» bad request data: «Request body too large.» Microsoft.AspNetCore.Server.Kestrel.Core.BadHttpRequestException: Request body too large. at Microsoft.AspNetCore.Server.Kestrel.Core.BadHttpRequestException.Throw(RequestRejectionReason reason) at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.Http1MessageBody.ForContentLength.OnReadStarting() at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.MessageBody.TryStart() at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.MessageBody.ConsumeAsync() at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol.ProcessRequests[TContext](IHttpApplication 1 application) at Microsoft.AspNetCore.Server.Kestrel.Core.Internal.Http.HttpProtocol.ProcessRequestsAsync[TContext](IHttpApplication 1 application)

HTTP Status Code for Larger Response 413 / 400

Part of Google Cloud Collective

I am getting below error when response is larger in size, We can fix below by enabling Streaming in Apigee ( Currently out of scope as needs work at all up streams)

413 Request Entity Too Large

400 «Message: Response is large»

5 Answers 5

Trending sort

Trending sort is based off of the default sorting method — by highest score — but it boosts votes that have happened recently, helping to surface more up-to-date answers.

It falls back to sorting by highest score if no posts are trending.

Switch to Trending sort

Well, it looks like it should be a 500 error. And, as a good practice, you should add some details in the body or a good and clear message, as said before by some wise people here.

All the 4xx errors indicates that the system is fine but your request is not. Some examples:

Request failed with status code 413

This forum has migrated to Microsoft Q&A. Visit Microsoft Q&A to post new questions.

Answered by:

Question

I can’t find any information on WSUS and HTTP 413 errors. Has anyone ever seen this? Any tips would be greatly appreciated!

Here is a larger clip of the log.

Answers

At this time, I think I’m all set. I was apparently looking for assistance on a problem that wasn’t a problem! I appreciate the help!

Return HTTP 413 (Request Entity Too Large) when http.max_content_length exceeded #2902

Comments

dbertram commented Apr 16, 2013

Currently elasticsearch drops the connection if http.max_content_length is exceeded. While this is acceptable behavior based on RFC2616 (http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.4.14), it’s not particularly friendly to client libraries.

Depending on the library being used, it can be difficult to determine the exact size of the HTTP request prior to actually sending it. Additionally, when the connection is simply closed, it leaves the underlying cause of the problem somewhat ambiguous without also inspecting the elasticsearch logs.

Proposed change: add an option to return HTTP 413 when http.max_content_length is exceeded instead of just dropping the connection.

Steps to repro the current behavior:

Expected: HTTP status code 413 (Request Entity Too Large)

Actual: Dropped connection client-side, and a TooLongFrameException in elasticsearch log

Here’s the output from curl:

The text was updated successfully, but these errors were encountered:

NSMutableURLRequest http status code 413

I have a web service. I use it to accept a base 64 string representation of a small (thumbnail size) image. This web service works awesome when using it with Fiddler and manually posting the request. When I run the same request with NSMutableURLRequest (or ASIHTTPRequest), it always returns a 413 status code (413 is Request Entity is Too Large).

Why would NSMutableURLRequest cause it to come up with a 413, whereas Fiddler returns 200 every time?

Here is my NSMutableURLRequest code. I could really use a push, if anybody has any ideas.

2 Answers 2

Trending sort

Trending sort is based off of the default sorting method — by highest score — but it boosts votes that have happened recently, helping to surface more up-to-date answers.

It falls back to sorting by highest score if no posts are trending.

Switch to Trending sort

When I see this bit of your code:

I’m guessing you have some whacky characters in your » POST_IMAGE_API_URL » #define, most likely in the parameters that you’re passing along.

You need to URL encode the URL string you pass to your URL request.

and pass «yourEncodedURL» in as a parameter to the URLRequest.

413 “Request Entity Too Large” error with uploading a file

In assets when uploading a medium size file I get this error:

Failed to load resource: the server responded with a status of 413 (Request Entity Too Large)

What does it mean? And how to fix?

3 Answers 3

413 errors occur when the request body is larger than the server is configured to allow. Here’s how you can fix it, depending on your web server:

You need to configure both nginx and php to allow upload size.

Nginx configuration

The client_max_body_size directive assigns the maximum accepted body size of client request, indicated by the line Content-Length in the header of request. If size is greater the given one, then the client gets the error «Request Entity Too Large» (413).

Spent a whole day working with the administrator at our web host trying to solve this problem. All the fixes suggested here and other sites did not help. The problem turned out to be with my third party VPN. Once that connections was turned off I was able to upload and install a Joomla extension without problem. So if you are getting a 413 message and nothing seems to fix it check that your VPN is not the culprit.

How to Fix 413 Request Entity too Large Error in WordPress

Error code	413 Request Entity Too Large
Error type	Client-side
Error variations	413 Payload Too Large HTTP Status Code 413
Error causes	Request too large PHP limits too low The page was not displayed because the request entity is too large.