Re: 413 Request Entity Too Large nginx/1.10.0 (Ubuntu)

2016-11-24 Пенетрантность webnetbt 
Нашли причину. Был подцеплен proxy.conf в нем прописан client_max_body_size
100m. Все поправили, работает.

чт, 24 нояб. 2016 г. в 18:08, Maxim Dounin :

> Hello!
>
> On Thu, Nov 24, 2016 at 05:25:24PM +0300, Andrey Kopeyko wrote:
>
> > On Thu, 24 Nov 2016, webne...@gmail.com wrote:
> >
> > > Доброго времени суток.
> > > Уже устал, не могу настроить загрузку видео файлов размером больше 170
> мб.
> > > Прописал   client_max_body_size 900m и в server и http и даже в
> location.
> > > Рестарт nginx пробую загрузить файл и ошибка:
> > > 2016/11/24 16:27:39 [error] 13314#13314: *9 client intended to send too
> > > large body: 174579043 bytes, client: 192.168.10.10, server: localhost,
> > > request: "POST /wp-admin/media-new.php HTTP/1.1", host:
> "192.168.11.96",
> > > referrer: "http://192.168.11.96/wp-admin/media-new.php;
> > >
> > > Что не так делаю, подскажите пожалуйста.
> >
> > Добрый день!
> >
> > Судя по всему, вам надо ещё и бэкенд (и php на нём) подкрутить на тему
> max
> > body size.
>
> Бекенд, конечно, подкрутить надо.  Но в данном случае, очевидно,
> дело не в бекенде, т.к. приведённая ошибка в логах nginx'а
> однозначно говорит о том, что срабатывает client_max_body_size в
> nginx'е.
>
> Надо смотреть, что именно написано в конфиге, скорее всего -
> редактируется не тот конфиг, или не тот server{} / location{} в
> нём.
>
> --
> Maxim Dounin
> http://nginx.org/
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: 413 Request Entity Too Large nginx/1.10.0 (Ubuntu)

2016-11-24 Пенетрантность Maxim Dounin 
Hello!

On Thu, Nov 24, 2016 at 05:25:24PM +0300, Andrey Kopeyko wrote:

> On Thu, 24 Nov 2016, webne...@gmail.com wrote:
> 
> > Доброго времени суток.
> > Уже устал, не могу настроить загрузку видео файлов размером больше 170 мб.
> > Прописал   client_max_body_size 900m и в server и http и даже в location.
> > Рестарт nginx пробую загрузить файл и ошибка:
> > 2016/11/24 16:27:39 [error] 13314#13314: *9 client intended to send too
> > large body: 174579043 bytes, client: 192.168.10.10, server: localhost,
> > request: "POST /wp-admin/media-new.php HTTP/1.1", host: "192.168.11.96",
> > referrer: "http://192.168.11.96/wp-admin/media-new.php;
> >
> > Что не так делаю, подскажите пожалуйста.
> 
> Добрый день!
> 
> Судя по всему, вам надо ещё и бэкенд (и php на нём) подкрутить на тему max 
> body size.

Бекенд, конечно, подкрутить надо.  Но в данном случае, очевидно, 
дело не в бекенде, т.к. приведённая ошибка в логах nginx'а 
однозначно говорит о том, что срабатывает client_max_body_size в 
nginx'е.

Надо смотреть, что именно написано в конфиге, скорее всего - 
редактируется не тот конфиг, или не тот server{} / location{} в 
нём.

-- 
Maxim Dounin
http://nginx.org/

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: 413 Request Entity Too Large nginx/1.10.0 (Ubuntu)

2016-11-24 Пенетрантность Alex Domoradov 
WP напрямую работает с nginx или проксирует на апач?

2016-11-24 16:28 GMT+02:00 :

> В php тоже настроил параметры post_max_size, upload_max_filesize. Но
> никаких результатов не дало.
>
> 24 ноября 2016 г., 17:25 пользователь Andrey Kopeyko 
> написал:
>
>> On Thu, 24 Nov 2016, webne...@gmail.com wrote:
>>
>> Доброго времени суток.
>>> Уже устал, не могу настроить загрузку видео файлов размером больше 170
>>> мб.
>>> Прописал   client_max_body_size 900m и в server и http и даже в location.
>>> Рестарт nginx пробую загрузить файл и ошибка:
>>> 2016/11/24 16:27:39 [error] 13314#13314: *9 client intended to send too
>>> large body: 174579043 bytes, client: 192.168.10.10, server: localhost,
>>> request: "POST /wp-admin/media-new.php HTTP/1.1", host: "192.168.11.96",
>>> referrer: "http://192.168.11.96/wp-admin/media-new.php;
>>>
>>> Что не так делаю, подскажите пожалуйста.
>>>
>>
>> Добрый день!
>>
>> Судя по всему, вам надо ещё и бэкенд (и php на нём) подкрутить на тему
>> max body size.
>>
>> Или же заливать видеофайлы по scp\ftp.
>>
>>
>>>
>> --
>> Best regards,
>> Andrey Kopeyko 
>> ___
>> nginx-ru mailing list
>> nginx-ru@nginx.org
>> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>>
>
>
>
> --
> С Уважением, Виталий.
>
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: 413 Request Entity Too Large nginx/1.10.0 (Ubuntu)

2016-11-24 Пенетрантность webnetbt 
В php тоже настроил параметры post_max_size, upload_max_filesize. Но
никаких результатов не дало.

24 ноября 2016 г., 17:25 пользователь Andrey Kopeyko 
написал:

> On Thu, 24 Nov 2016, webne...@gmail.com wrote:
>
> Доброго времени суток.
>> Уже устал, не могу настроить загрузку видео файлов размером больше 170 мб.
>> Прописал   client_max_body_size 900m и в server и http и даже в location.
>> Рестарт nginx пробую загрузить файл и ошибка:
>> 2016/11/24 16:27:39 [error] 13314#13314: *9 client intended to send too
>> large body: 174579043 bytes, client: 192.168.10.10, server: localhost,
>> request: "POST /wp-admin/media-new.php HTTP/1.1", host: "192.168.11.96",
>> referrer: "http://192.168.11.96/wp-admin/media-new.php;
>>
>> Что не так делаю, подскажите пожалуйста.
>>
>
> Добрый день!
>
> Судя по всему, вам надо ещё и бэкенд (и php на нём) подкрутить на тему max
> body size.
>
> Или же заливать видеофайлы по scp\ftp.
>
>
>>
> --
> Best regards,
> Andrey Kopeyko 
> ___
> nginx-ru mailing list
> nginx-ru@nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-ru
>



-- 
С Уважением, Виталий.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: 413 Request Entity Too Large nginx/1.10.0 (Ubuntu)

2016-11-24 Пенетрантность Andrey Kopeyko 

On Thu, 24 Nov 2016, webne...@gmail.com wrote:


Доброго времени суток.
Уже устал, не могу настроить загрузку видео файлов размером больше 170 мб.
Прописал   client_max_body_size 900m и в server и http и даже в location.
Рестарт nginx пробую загрузить файл и ошибка:
2016/11/24 16:27:39 [error] 13314#13314: *9 client intended to send too
large body: 174579043 bytes, client: 192.168.10.10, server: localhost,
request: "POST /wp-admin/media-new.php HTTP/1.1", host: "192.168.11.96",
referrer: "http://192.168.11.96/wp-admin/media-new.php;

Что не так делаю, подскажите пожалуйста.


Добрый день!

Судя по всему, вам надо ещё и бэкенд (и php на нём) подкрутить на тему max 
body size.


Или же заливать видеофайлы по scp\ftp.





--
Best regards,
Andrey Kopeyko ___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

413 Request Entity Too Large nginx/1.10.0 (Ubuntu)

2016-11-24 Пенетрантность webnetbt 
Доброго времени суток.
Уже устал, не могу настроить загрузку видео файлов размером больше 170 мб.
Прописал   client_max_body_size 900m и в server и http и даже в location.
Рестарт nginx пробую загрузить файл и ошибка:
2016/11/24 16:27:39 [error] 13314#13314: *9 client intended to send too
large body: 174579043 bytes, client: 192.168.10.10, server: localhost,
request: "POST /wp-admin/media-new.php HTTP/1.1", host: "192.168.11.96",
referrer: "http://192.168.11.96/wp-admin/media-new.php;

Что не так делаю, подскажите пожалуйста.
-- 
С Уважением, Виталий.
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Request Entity Too Large

2013-03-29 Пенетрантность Igor Sysoev 
On Mar 28, 2013, at 17:34 , Aleksandr Sytar wrote:

 Я бы резюмировал бы так - дайте возможность вносить многострочные комментарии

Наверное, это стоит сделать в виде:

disable server {
...
}

disable location /dir/ {
...
}

и в более общем виде

disable {
...
}

Более короткое слово off хуже, потому что его сложно искать - будет
совпадений с флагами директив - on/off.


--
Igor Sysoev
http://nginx.com/services.html

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Request Entity Too Large

2013-03-28 Пенетрантность Андрей Василишин 

28.03.2013 0:38, Maxim Dounin пишет:


Я стесняюсь спросить - а что показывает nginx -V?  В nginx'е из
коробки - влиять не должно, но сторонние модули такие модули.



Сторонних модулей нет, nginx -V приводил в первом сообщении.
По поводу того, что нгинкс не обновлялся - я соврал, обновлся до 
стандартного дебиановского nginx-extras 1.2.1,потом я его обновил до 
собственной сборки из дебиановских сорцов nginx-extras 1.2.4 (из сборки 
исключены все third party модули), но и с учетом множества рестартов 
новый 1.2.4 продолжал выдавать все туже ошибку, в дебаг-логе ничего 
подозрительного при этом нет. Потом поменял местами инклюд и еще один 
рестарт исправил ошибку.


___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Request Entity Too Large

2013-03-28 Пенетрантность Aleksandr Sytar 
28 марта 2013 г., 17:29 пользователь denis de...@webmaster.spb.ru написал:
 1) Не использовать include вида sites/*.  Вообще конфигурить
 nginx одним файлом - гораздо приятнее и удобнее, а главное -
 понятнее, особенно новичкам.

 Ага. Особенно когда сайтов не 1-2, а десятков 5, причём конфигурация
 типовая. Плюс на каждый - ещё пяток server-секций, с редиректами на основной
 сайт. И теперь представим, что нам надо отключить 1 сайт с его
 редиректами-алиасами. Автоматом (не ручками). В случае с conf/* - просто
 удаляем/переносим 1 файл, и ВСЁ. А в 1... привет неделя секса с sed?
 Вручную? А если надо поручить такое отключение тому самому новичку?
 Усложним - отключать и подключать домены будем по нескольку раз в день.
 Теперь понадобилось добавить 1 формат картинок на все домены. Правлю
 conf/static.conf например, и всё, на всех доменах нормальный формат.
 А с единым - привет сед? Плюс хорошо бы потом проверить все домены, что у
 всех единая строка с картинками.
 А теперь добавим еще location всем основным доменам. Тут я уже даже не
 представляю, как это сделать кроме как вручную каждому сайту.
 Теперь добавим конфиги в систему контроля версий. Что удобнее
 контролировать, когда у нас 1 файл и надо откатить 1 домен из старой
 ревизии, при этом сохранив десяток появившихся с того момента доменов, или
 когда все домены в отдельных файлах?

 Да, а на 1 сервере у меня около 1к доменов. И вариант поправить вручную
 идёт лесом, молча и сразу.

 Про понятнее - найти что-то глазами в 100кб конфиге сильно сложнее, чем в
 пачке логически раскиданных, вдобавок суммарно далеко не 100кб (вспоминаем
 вынесение типовых блоков в 1 файл). Плюс grep -l всегда поможет найти нужный
 файл в пару кб, а его уже глазами целиком ухватить можно.

 И да, если используется ispmanager, несколько раз он бил мне этот единый
 конфиг, поэтому давно конфиг разбивается на сайты и инклудится. Потом очень
 геморно - переписывать настройки под 2-10 сайтов, которые он каким-то
 образом дропнул.

 Так что в каком-то странном мире Вы живете.

Я бы резюмировал бы так - дайте возможность вносить многострочные комментарии
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Request Entity Too Large

2013-03-28 Пенетрантность Daniel Podolsky 
 При этом директива include - не гарантирует какой-либо порядок
 включения файлов при использовании масок, что плохо отражается на
Вот это сюрприз! Может быть - сделаете нам гарантию алфавитного порядка?

Хотите - я feature request в track оформлю? :)
___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Request Entity Too Large

2013-03-28 Пенетрантность Maxim Dounin 
Hello!

On Thu, Mar 28, 2013 at 05:29:22PM +0400, denis wrote:

 28.03.2013 16:03, Maxim Dounin пишет:
 При этом директива include - не гарантирует какой-либо порядок
 включения файлов при использовании масок, что плохо отражается на
 работоспособности конфигов, использующих директиву include для
 включения множества блоков server{} и при этом не использующих
 параметр default_server директивы listen.
 При чём тут вообще default_server? У меня он задаётся в отдельном
 конфиге, 000_default, и с этим проблем нет.

Тогда в чём ваша проблема с первым видело основной блок и 
привет?

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

 Очевидных решений два:
 
 1) Не использовать include вида sites/*.  Вообще конфигурить
 nginx одним файлом - гораздо приятнее и удобнее, а главное -
 понятнее, особенно новичкам.
 Ага. Особенно когда сайтов не 1-2, а десятков 5, причём конфигурация
 типовая. Плюс на каждый - ещё пяток server-секций, с редиректами на
 основной сайт. И теперь представим, что нам надо отключить 1 сайт с
 его редиректами-алиасами. Автоматом (не ручками). В случае с conf/*

Задача автического управления большими конфигами - она 1) совсем 
отдельная, 2) файликами всё равно полноценно не решается, и 3) от 
использования или не использования include * никак не зависит, 
т.к. скрипту всё равно, что сделать на выходе.

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

Так что несмотря на все кажущиеся достоинства include * - я 
крайне негативно отношусь к этому механизму.

[...]

 Может быть, но в ситуации, когда порядок вообще говоря не
 определён - подобный вывод только собъёт с толку.
 Он покажет, как нгинх распарсил конфиги, в каком порядке загрузил файлы итд.

Чем вам поможет порядок, в котором nginx загрузил файлы в этот 
раз, если в следующий раз - этот порядок вполне может быть другим?

-- 
Maxim Dounin
http://nginx.org/en/donation.html

___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru

Re: Request Entity Too Large

2013-03-28 Пенетрантность Андрей Василишин 

Дико извиняюсь!
Аж самому стало стыдно и немного интересно, как оно работало раньше.

В общем было еще
include /etc/nginx/sites-enabled/*;

это уже когда от безысходности начал приводить конфиг к общему виду (как 
на других серверах) дописал машинально .conf и отправил строку с 
инклюдом в самый низ http {}


а в директории /etc/nginx/sites-enabled/ лежал старый конфиг с 
расширением conf.1 в котором client_max_body_size 10m;


и в нем же есть server_name _default
куда, как я присмотрелся еще раз в логи, и попал запрос.

2013/03/27 22:18:13 [notice] 26193#0: *6484 a client request body is 
buffered to a temporary file /tmp/005612, client: 10.0.0.5, server: 
_default, request: POST /encoder2/ajax/update/coding-files/ HTTP/1.1, 
host: 10.0.0.12, referrer: http://10.0.0.12/encoder2/;


Ради эксперимента перенес назад (над client_max_body_size 2048m; ) строку
include /etc/nginx/sites-enabled/*.conf;
и сделал рестарт, все работает никаких ошибок не выдает. Еще раз 
извиняюсь за излишнюю панику.







___
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru