Геннадий, добрый день.
При всем уважениии, вы невнимательно просмотрели эту тему Вы задали вопросы и выдвинули аргументы на которые уже есть ответы и всяческое взаимопонимание.
> > limit_req_skip "zone" "$var_to_skip" для
> т.е. придется вводить
> лишнюю директиву
Игорь уже пояснил свою позицию и написал свои аргументы. Тема глобальных директив уже закрыта.
> limit_req_skip для локальной
> при обработке запросов к 99%
Вы недопоняли (или я недообъяснил) limit_req_skip предлагалась локальной (контекст location). Но уже не предланается. Согласен с аргументами автора nginx.
> тогда вообще не понятно в
> чем проблема,
> скриптом ведь можно любой
> конфиг сгенерить.
Я же говорю - вы не поняли суть проблемы.
Я не говорю, что мне влом прописать 100 строк в конфигах.
Я говорю о том, что НЕИЗВЕСТНО какие location в каких серверах надо тормозить, а какие не надо. Но я точно знаю, что надо ограничиваь скорость к .php. Изучать 100 серверов можно. Но проще отказаться от фичи ограничения скорости.
Nginx сегодня не позволяет ограничивать запросы по условию.
И, конечно, как уже и писал, мне без разницы где прописать ограничение и сколько раз.
Важно понимать, что сегодня прописывание limit_req в location "/" в общем случае - бестолковое занятие. Тк есть и картинки и стили и js и прочая лабудень. Юзер кликнул, а на сервер сотня запросов, а ленко и больше.
Поэтому надо отделять запросы скорость к которым надо ограничивать (скрипты) от запросов к которым НЕ надо ограничивать скорость (статика). Сейчас это можно сделать только описываем разных location'ов для статики и для динамики.
В этом и проблема. Сейчас нужно индивидуально настраевать каждый сервер бакенда. Скриптом определить в каком location там статика, а в каком динамика - НЕВОЗМОЖНО. Поэтому невозможно сгенерировать нужный конфиг.
Но по $uri это можно сделать в большинстве случаев. Да, не во всех. *.gif МОЖЕТ оказаться динамикой, но .php статикой уж врядли будет являтся. При этом в .gif автоматические искатели уязвимостей врядли смогут заподозрить скрипт, в отличии от *php.
Я все равно плохо объяснил?
> замечательно. и что мешает
> в template для 99
> серверов внести дефолтовые
> limit_req ограничения,
Не о дефолтном просто речь. А об ограничении, которое работает только для определенных uri в location /. Куда его внести - дело десятое.
Своими словами:
location / {
ограничить_скорость_запросов_к_$uri=~/\.php/_до_1r/s nodelay burst=3
}
Возмем cms tiki-wiki. Там php в корне, а статика по мульену подкаталогов.
Вот чтобы ограничение работало только для php надо прописать ограничение на корень, а потом описать тот самый мульен подкаталогов со статикой. Но СНОВА беда. В каждом подкаталоге со статикой есть хотя бы один index.php (с редиректом) - как его тормозить не тормозя статики?
Насколько я понимаю, такая же ситуация с joomla и прочей cms и board'ами. Они уже есть. И в настоящее время разумно ограничить скорость с такими движками невозможно.
> вообще, я так вижу, что
> конфиг nginx можно
> рассматривать
> как низкоуровневый язык
> ассемблера, больше всего
> nginx
Геннадий, я вижу, что вы любите nginx, мне тоже он нравится. Вот и вся философия.
> напиминает nasm, и там и там:
> "Its syntax is designed
> to be simple and easy to understand". а свой
> собственный
> генератор конфига можно
> рассматривать как
> высокоуровневый
> специализированный язык. и
Повторяюсь не менее многократно Вашего :-)
Вопрос не в том как сгенерить конфиги. Вопрос в том, что то, что я прошу сгенерить (равно как и написать в ручную) НЕВОЗМОЖНО. Прочитайте внимательнее первое письмо. В этом (скиптовании и конфигогенерации) я не лентяй ;-)
> если какую-то feature можно
> реализовать средствами
> генератора конфига, - тогда
> особо
> нет смысла просить
> реализовывать эту фичу в
> самом nginx.
Именно поэтому прошу реализовать :-)
В настоящее время остался вопрос.
Можно ли реализовать директиву в контексте location
limit_req_if зона burst=N [nodelay] $var
Которая будет учытывать при подсчете скорости не все запросы, а те, у которых $var == true.
Насколько сложна такая реализация?
С уважением,
Владимир
