Request Entity Too Large

[Maxim Dounin]

Hello!

On Thu, Mar 28, 2013 at 02:24:53PM +0400, denis wrote:

> 28.03.2013 2:38, Maxim Dounin пишет:
> >>Не думал, что порядок вставки инклюда с виртуалхостами влияет на к
> >>ним применение директив описанных в http { }
> >Я стесняюсь спросить - а что показывает nginx -V?  В nginx'е из
> >коробки - влиять не должно, но сторонние модули такие модули.
> >
> Опыт показывает, что влияет очень сильно, вплоть до того, что
> поддомены приходилось описывать с именами вида 000_sub.domain, иначе
> первым видело основной блок и привет. (инклуд вида sites/*)
> Хотя явно столкнулись только с 1 версией, не помню уже какой, но
> теперь поддомены всегда называем так, чем ниже уровень, тем больше
> нулей.
> Более того, на 1 сервере даже игнорировались эти нули и файлы
> читались в порядке их создания. Явный баг был.

"Правда, только ... и не выиграл, а проиграл." (c)

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

http://nginx.org/ru/docs/http/ngx_http_core_module.html#listen

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

При этом директива include - не гарантирует какой-либо порядок 
включения файлов при использовании масок, что плохо отражается на 
работоспособности конфигов, использующих директиву include для 
включения множества блоков server{} и при этом не использующих 
параметр default_server директивы listen.  

Очевидных решений два:

1) Не использовать include "вида sites/*".  Вообще конфигурить 
nginx одним файлом - гораздо приятнее и удобнее, а главное - 
понятнее, особенно новичкам.

2) Расставлять "listen ... default_server" правильно.

Отдельно может доставить попытка использовать имена серверов, 
заданные регулярными выражениями, ибо оные регулярные выражения - 
проверяются в порядке описания в конфигурационном файле 
(http://nginx.org/r/server_name/ru).  Каковой порядок, как мы уже 
выяснили выше, в случае "include sites/*" не определён.

Всё это относится к типичных ошибкам при конфигурировании nginx'а 
вообще, и к проблемам использованного по умолчанию конфига во 
многих пакетах в linux'е - в частности.  И, без сомнения, может 
являться причиной наблюдаемых проблем.  Однако проблема в этом 
случае - в неконсистентности конфига, загружаемого по "include 
sites/*", а не в том, что стоит раньше, client_max_body_size - или 
include.

> И кстати порядок имеет значение, и когда описываем limit_zone, и
> кэши, и proxy_pass...
> Очень грустно, что нет вывода итоговой конфигурации, сильно
> облегчило бы жизнь. Думаю, задача максимум в 10 строк решается,
> nginx-у делаем ключик типа апачевского -S и на него вывод.

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

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