Hello! On Sat, Aug 10, 2013 at 11:43:31PM +0400, Михаил Монашёв wrote:
> Здравствуйте, Валентин. > > >> set на уровне http был бы очень удобен порой. Обходить это через > >> map 1 $var { > >> default "value"; > >> } > >> неудобно. > > > http://nginx.org/en/docs/faq/variables_in_config.html > > Признаюсь, что не въехал в ответ по ссылке. Все слова знакомые, а > собранные вместе смысл никакой в моей голове не приобретают. Тупею, > видимо. :-) > > Опишу задачу. Мне надо было как-то писать в аксес-лог кэш-зону, чтобы > потом по логам считать эффективность каждой кэш-зоны. Встроенную > переменную я не знаю, поэтому решил создать переменную через set. Там, > где запросы проксируются, я присваивал через set соответствующей > переменной значение, равное имени кэшзоны. Но не все запросы > проксируются и в логе вместо значения переменной пишется пустая > строка, что неудобно для парсинга лога. Брать переменную в кавычки > тоже неудобно. > > Для таких запросов я хотел присвоить этой переменной дефолтное > значение "-". Писать в каждом блоке server{} set или include посчитал > лишним и вставил в http{} вот такие строчки: > > # set нельзя делать на уровне http, поэтому делаем присваивание через > map > map 1 $cache_zone_for_logging { > default "-"; > } > > Т.е. я хотел использовать set для инициализации переменной, которая > потом может меняться. > > На мой примитивный взгляд кажется нелогичным иметь иерархию блоков > конфига, иметь наследование с вышестоящих уровней иерархии и разрешать > set-у работать на уровне http{}. Всмысле - _не_ разрешать? Проблема состоит в том, что set - это директива модуля rewrite, которая не наследуется, выполняется вместе с остальными директивами в rewrite-фазе и т.п. Вводить директиву set на уровне http с совершенно другой семантикой - это не очень хорошая идея. -- Maxim Dounin http://nginx.org/en/donation.html _______________________________________________ nginx-ru mailing list nginx-ru@nginx.org http://mailman.nginx.org/mailman/listinfo/nginx-ru