I have a server less API with AWS API Gateway and Lambda function. I am using custom authorization function for authorization. The header is too large and due to which I am getting this error. Normally, for an nginx server, I would have changed the nging config and this would have been fixed. I don’t know how to take care of this in AWS API Gateway.
asked May 26, 2016 at 23:12
Mandeep SinghMandeep Singh
7,35419 gold badges62 silver badges100 bronze badges
2
The 10MB payload limit applies to the message body. If you’re running into limits on the header size, unfortunately these cannot be configured. They are stated on the CloudFront page: http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/cloudfront-limits.html
In particular:
Custom headers: maximum length of a header name 256 characters
Custom headers: maximum length of a header value 2,048 characters
Custom headers: maximum length of all header values and names combined 10,240 characters
answered May 31, 2016 at 18:40
I found that gunzipping the content solves this issue (code inspired from this blog post https://techblog.commercetools.com/gzip-on-aws-lambda-and-api-gateway-5170bb02b543)
See this example with Typescript:
export async function getResponse(savedItems) {
return new Promise<APIGatewayProxyResult>((resolve, reject) => zlib.gzip(JSON.stringify(savedItems), (error, gzippedResponse) => {
if (error) {
reject(error);
console.error(error);
} else {
const response: APIGatewayProxyResult = {
statusCode: 200,
headers: {
'Access-Control-Allow-Origin': '*',
'Access-Control-Allow-Credentials': true,
'Content-Encoding': 'gzip',
},
isBase64Encoded: true,
body: gzippedResponse.toString('base64'),
};
console.info(`response statusCode: ${response.statusCode} body length: ${response.body.length}`);
resolve(response);
}
}));
}
answered Nov 3, 2021 at 20:52
Sovattha SokSovattha Sok
6101 gold badge7 silver badges18 bronze badges
В редких случаях, но бывает, что во время загрузки больших файлов на веб-сайт возникает ошибка, которую возвращает веб-сервер Nginx — 413 Request Entity Too Large. Ошибка появляется, при попытке загрузить на сервер слишком большой файл чем это разрешено на сервере. Дальше рассмотрим описание ошибки 413 Request Entity Too Large а также методы её исправления на стороне веб-сервера Nginx.
Что означает ошибка 413
Ошибка 413 или Request Entity Too Large расшифровывается как «объект запроса слишком велик» или простыми словами объем передаваемых данных слишком большой. Ошибка возвращается в случае, если сервер не может обработать запрос по причине слишком большого размера тела запроса (или большого файла). Снимок экрана с ошибкой изображен ниже:
По умолчанию в Nginx установлен лимит на размер тела запроса который равен 1 МБ. Если запрос превышает установленное значение, вы увидите ошибку 413 Request Entity Too Large.
Как исправить
Для исправления ошибки 413 следует увеличить допустимый лимит. Увеличить размер тела запроса и соответственно, загружаемых файлов, можно путем использования client_max_body_size. Опциюя доступна для использования в директивах http, server или location в конфигурационном файле /etc/nginx/nginx.conf или в конфигурационном файле веб-сайта.
Откройте конфигурационный файл nginx.conf при помощи любого текстового редактора:
$ sudo nano /etc/nginx/nginx.conf
Вписываем строчку в секцию http:
$ client_max_body_size 100M
100 — максимальный размер файла в мегабайтах который можно загрузить на веб-сайт, в данном случае — 100 мегабайт. Если в распоряжении имеется несколько веб-сайтов и необходимо ограничить загрузку на все сайты сразу, то строку client_max_body_size необходимо вписываем в раздел блока http. Если ограничение на загрузку необходимо выставить только для конкретного сайта, то строку client_max_body_size необходимо добавить в блок server конфигурационного файла сайта, который по умолчанию находиться в /etc/nginx/sites-available/имя_файла_с_конфигурацией:
Когда ограничение на загрузку необходимо выставить только для конкретного раздела на сайте, строку client_max_body_size необходимо вписать в директиву location конфигурационного файла сайта, который по умолчанию находиться в /etc/nginx/sites-available/имя_файла_с_конфигурацией:
Как только были внесены изменения в конфигурационные файлы, сохраните их, закройте текстовый редактор и проверьте синтаксис конфигурационных файлов на наличие ошибок при помощи команды:
$ sudo nginx -t
Вы можете увидеть следующие строки:
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.
Sergey G. Brester dixit:
> How can we configure these 60 seconds?
Unfortunately there is no config value for that. it is fix coded at the
moment.
Ouch.
> piping something (here, restic) through logger(1) considers the
> timestamp of when the line from stdin was begun, but sends the line
> only when the `n` arrives, which may be later if a line is not
> immediately finished
Longer than 1 minute?
Yes.
Hmm… I don’t think it is good practice for the logging
I wouldn’t do it like this either, but this is simply stdout of
the program invoked, and it’s therefore both “fine” and outside
of my control.
and may introduce another issues (especially if it is multi-threaded).
Again, not under my control, but I’d assume they only output
to stdout from one thread, or something.
Anyway, internal line-buffering on stdout could solve that.
Internal line-buffering on stdout, on the logger(1) side, is
precisely what’s causing this. (And it’s probably even the
correct behaviour, as this allows one to time output.)
> Apache 2 long-running requests often show up “late” in access_log but
> with the original timestamp
You can surely configure apache to log response time (instead or
additionally to request time).
But why would I even want to? fail2ban being so allergic to
“reordered” log lines is the problem, not programs logging
things “late” but with earlier timestamps.
Anyway if you don’t need to know timestamp at all (it is irrelevant for
That’s not the point either. But adding like 10 minutes tolerance
instead of just one would solve most of these cases and still be
below the 30/60, depending on the zone involved, minutes timezone
offset, as the warning is “just” to detect timezone divergencies.
bye,
//mirabilos
—
“It is inappropriate to require that a time represented as
seconds since the Epoch precisely represent the number of
seconds between the referenced time and the Epoch.”
— IEEE Std 1003.1b-1993 (POSIX) Section B.2.2.2
Linux, Программное обеспечение
- 21.01.2015
- 34 985
- 5
- 03.04.2020
- 22
- 21
- 1
- Содержание статьи
- Описание ошибки
- nginx
- Apache
- httpd.conf
- .htaccess
- PHP
- Комментарии к статье ( 5 шт )
- Добавить комментарий
Описание ошибки
413 Request Entity Too Large
Данная ошибка может появиться в том случае, если вы загружаете какой-либо файл на сервер и размер этого файла превышает максимально разрешенный в конфиге в веб-сервера (например, в nginx по умолчанию установлено ограничение в 1 МБ). Для того, чтобы это исправить, необходимо внести определенные правки в файл конфигурации, который может быть разным, в зависимости от используемого веб-сервера. Ниже будут приведены примеры для самых популярных веб-серверов:
nginx
Максимальный размер файла указывается параметром client_max_body_size. Поэтому, достаточно прописать параметр и новое значение в любой конфиг, который использует nginx для сайта, на котором у вас появилась эта проблема. Получится должно что-то примерно следующее:
server {
...
client_max_body_size 4m;
...
}
Где 4m — это 4 Мб. Для установки лимита в 32 Мб, надо соответственно написать client_max_body_size 32m, и т. д.
После изменения настроек нужно обязательно перезагрузить конфиг в nginx.
Apache
httpd.conf
Размер файла, допустимого для заливки, можно отрегулировать в главном конфиге Apache, который можно найти по адресу /etc/httpd/conf/httpd.conf (в CentOS) или /etc/apache2/apache2.conf (в Debian/Ubuntu). Задается он параметром LimitRequestBody, и ему можно прописать любое нужное значение в байтах. Например, так выглядит ограничение в 32 МБ:
LimitRequestBody 33554432Для применения настроек нужно перезагрузить веб-сервер Apache.
.htaccess
Очень часто у веб-сервера Apache для настройки определенного сайта используется файл .htaccess, который лежит в корневой директории веб-сайта. Удобство данного метода в том, что Вы можете прописать нужные настройки, которые будут применяться только для данной директории и веб-сайта, который данную директорию использует.
Если используемый для загрузки скрипт находится в какой-то поддиректории, где имеется свой файл .htaccess, то его настройки будут иметь больший приоритет!
Для этого, нужно либо открыть уже существующий файл .htaccess (или создать, в случае отсутствия) и добавить туда следующие строки (32 МБ в байтах):
LimitRequestBody 33554432Если для работы сайта и заливки файла используется PHP, то нужно добавить еще другую строчку:
php_value upload_max_filesize 32MPHP
Если при заливке файла используется PHP скрипт, то для PHP имеются отдельные настройки максимального размера файла. Для их изменений потребуется внести правку в файл php.ini, который расположен по адресу /etc/<версия php>/fpm. Открываем его любым текстовым редактором и находим следующие строки:
upload_max_filesizepost_max_sizeИ выставляем им нужные значения, например 4M (т. е. 4 МБ).
После внесения правок просто перезагружаем php, и проверяем работу.
🔍 Простой поиск по базе знаний
Ошибка HTTP 413 (Request Entity Too Large Error) означает, что клиент отправил слишком большой запрос на сервер.
Ошибка может возникать при отправке серверу запросов большого объёма (загрузке файлов, к примеру).
При работе с WordPress появляется довольно часто.
Одна из причин — это дефолтные настройки nginx, а точнее параметра client_max_body_size, который по умолчанию равен 1m, то-есть появляется при загрузке файлов больше 1 мегабайта.
Вообще дефолтные настройки — это всегда плохо…
Вот, что по этому поводу говорится на сайте nginx:
| Синтаксис: | client_max_body_size размер; |
|---|---|
| Умолчание: |
client_max_body_size 1m; |
| Контекст: | http, server, location |
Задаёт максимально допустимый размер тела запроса клиента, указываемый в поле “Content-Length” заголовка запроса. Если размер больше заданного, то клиенту возвращается ошибка 413 (Request Entity Too Large).
Следует иметь в виду, что браузеры не умеют корректно показывать эту ошибку. Установка параметра размер в 0 отключает проверку размера тела запроса клиента.
В файл nginx.conf, в секцию http, добавить/изменить:
client_max_body_size 100m;
где, 100M — максимальный объём запроса (файла). В данном случае — 100 мегабайт. Приставка M — мегабайты, G — гигабайты. В принципе можно задать и больше, например 512мб.