Hello!
On Mon, Feb 01, 2016 at 11:03:16PM +0600, Pavel V. wrote:
[...]
> > Сделать явный отдельный параметр if - можно, но сколько-нибудь
> > принципиальной разницы нет. В то же время не факт, что мы хотим
> > тут усложнять синтаксис.
>
> Если условия везде одинаковые, то они задаются map-ом, пусть и чуть более
> громоздким конфигом, чем с параметром if. Принципиальная разница появляется
> только в том, что в разные директивы limit_req в параметр if можно задать разные
> условия.
Если условия вдруг разные - то они, при желании, аналогично
задаются чуть более сложным map'ом. Так что это, в общем-то, в
первую очередь вопрос синтаксиса. Принципиально разницы тут не
прослеживается.
Плюсы, которые видны: чуть проще синтаксис (не всякий пользователь
nginx'а готов писать логику с использованием map'ов), и можно
менять burst/nodelay без добавления поддержки переменных в
соответствующих параметрах. Но я совершенно не уверен в
востребованности всего этого.
[...]
> > Если хочется программировать - стоит подумать о том, чтобы
> > вытащить результаты ограничений в переменные, и дальше
> > программировать с помощью директив rewrite-модуля же.
>
> Можно увидеть пример конфигурации, как она могла бы быть заданной
> таким способом?
> Например, для двух условий: $is_spider и $is_vip.
> Если $is_vip - ограничений вообще нет, если $is_spider - одна зона
> (ограничения), иначе вторая (другие ограничения)?
Вот конкретно для такой задачи - всё решается существующими
механизмами, ничего изобретать не надо. Как-то так:
map $is_vip$is_spider $user {
10 "";
11 "";
01 "";
00 $binary_remote_addr;
}
map $is_vip$is_spider $spider {
10 "";
11 "";
01 $binary_remote_addr;
00 "";
}
limit_req_zone $spider zone=spider:1m rate=1r/m;
limit_req_zone $user zone=user:1m rate=10r/m;
limit_req zone=spider;
limit_req zone=user;
Что до использования переменных и программирования, то оно может
быть нужно в случаях сложной логики - e.g., если мы хотим
отвергать запрос только в случае срабатывания нескольких
ограничений одновременно. Или хотим даже при срабатывании
одного ограничения увеличивать остальные счётчики.
Как это должно выглядеть - надо думать, вероятно экспротировать
счётчики в каких-то переменных, задаваемых через limit_req_zone, и
строить логику на обращениях к ним, как-то так:
limit_req_zone $binary_remote_addr zone=addr:1m rate=1r/m
variable=$limit_addr_count;
limit_req_zone $server_name zone=host:1m rate=1r/m
variable=$limit_host_count;
set $limit $limit_addr_count:$limit_host_count;
if ($limit ~ "\d\d+:\d\d+") {
return 401;
}
Но, опять же, не факт, что мы вообще что-то подобное хотим делать.
> >> Возможность безусловного отключения ограничений, наследованных с
> >> предыдущего уровня.
>
> > Это уже записано в TODO, возможность отказаться от унаследованных
> > ограничений, безусловно, нужна.
>
> >> Из планируемых вещей также есть мысли по поводу добавления параметра "dry-run".
>
> > Да, сделать возможность проверки ограничений без их реального
> > применения - тоже уже в TODO.
>
> Судя по всему, это должен быть параметр директивы limit_req_zone. Как он зовется
> в вашем TODO?
Скорее, отдельная директива, аналогично limit_req_status /
limit_req_log_level. В TODO значится:
Dry-run for limit_req. See also:
http://mailman.nginx.org/pipermail/nginx/2016-January/049648.html
> "Patches are welcome"? По этим двум пунктам они достаточно тривиальны.
Да. На всякий случай оставлю эту ссылку здесь:
http://nginx.org/ru/docs/contributing_changes.html
--
Maxim Dounin
http://nginx.org/
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://mailman.nginx.org/mailman/listinfo/nginx-ru
