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