ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
Nginx-ru mailing list archive (nginx-ru@sysoev.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Request Entity Too Large



28.03.2013 19:29, 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, и с этим проблем нет.
Тогда в чём ваша проблема с "первым видело основной блок и
привет"?
основной блок == основной домен...
то есть описываем site.ru www.site.ru, и им же захватывало прочие поддомены этого домена. Подробнее уже не скажу, год+ прошёл. Возможно просто баг был.

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

В то же время, плач на тему "у меня ничего не работает" -
сводящийся к тому, что кривой конфиг получился из-за использования
вопрошающим "include *" - я тут наблюдаю с поразительной
регулярностью уже который год.
Там все ошибки -- невнимательность/непонимание пользователей, что в итоге и выясняется. Но сильно мешает отладке отсутствие вменяемого конфтеста + вывода, какой (под)домен в каком конфиге и на какой строке начинает описание, а-ля апач хотя бы. Плюс полный листинг итоговой конфигурации помогает увидеть "нежданчика" в виде установленной переменной/локейшена/итд там, где его никто не ждал. В любом случае механизм инклудов нужный, но требует аккуратности, да. Именно поэтому я предпочитаю, когда всё по файлам, всё проверено и генерируется автоматически + контроль версий. Почти все проблемы - человеческий фактор, и без него сюрпризов почти не бывает (поэтому и указываю так на sed и проблемы скриптования изменений).

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

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


 




Copyright © Lexa Software, 1996-2009.