Re: Request Entity Too Large

[denis <denis@xxxxxxxxxxxxxxxx>]

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 файл, и ВСЁ. А в 1... привет неделя секса с sed? 
Вручную? А если надо поручить такое отключение тому самому "новичку"? 
Усложним - отключать и подключать домены будем по нескольку раз в день.
Теперь понадобилось добавить 1 формат картинок на все домены. Правлю 
conf/static.conf например, и всё, на всех доменах нормальный формат.
А с единым - привет сед? Плюс хорошо бы потом проверить все домены, что 
у всех единая строка с картинками.
А теперь добавим еще location всем основным доменам. Тут я уже даже не 
представляю, как это сделать кроме как вручную каждому сайту.
Теперь добавим конфиги в систему контроля версий. Что удобнее 
контролировать, когда у нас 1 файл и надо откатить 1 домен из старой 
ревизии, при этом сохранив десяток появившихся с того момента доменов, 
или когда все домены в отдельных файлах?
Да, а на 1 сервере у меня около 1к доменов. И вариант "поправить 
вручную" идёт лесом, молча и сразу.
Про понятнее - найти что-то глазами в 100кб конфиге сильно сложнее, чем 
в пачке логически раскиданных, вдобавок суммарно далеко не 100кб 
(вспоминаем вынесение типовых блоков в 1 файл). Плюс grep -l всегда 
поможет найти нужный файл в пару кб, а его уже глазами целиком ухватить 
можно.
И да, если используется ispmanager, несколько раз он бил мне этот 
"единый конфиг", поэтому давно конфиг разбивается на сайты и инклудится. 
Потом очень геморно - переписывать настройки под 2-10 сайтов, которые он 
каким-то образом дропнул.
Так что в каком-то странном мире Вы живете.

> 2) Расставлять "listen ... default_server" правильно.
Еще раз, при чём тут вообще default_server

> Отдельно может доставить попытка использовать имена серверов,
> заданные регулярными выражениями, ибо оные регулярные выражения -
> проверяются в порядке описания в конфигурационном файле
> (http://nginx.org/r/server_name/ru).  Каковой порядок, как мы уже
> выяснили выше, в случае "include sites/*" не определён.
Практика показывает, что нормально всё работает. Есть особенности с тем, 
что нельзя описывать главный сайт с точкой или *, и тогда всё работает. 
Плюс опять же, 0_sub.site.
Уже приводил линк на эту тему, 
http://dragonflybsd.blogspot.ru/2012/07/nginx-regex-servername.html
> Может быть, но в ситуации, когда порядок вообще говоря не
> определён - подобный вывод только собъёт с толку.
Он покажет, как нгинх распарсил конфиги, в каком порядке загрузил файлы итд.

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