Re: limit_req_zone, переменный rate

[Maxim Dounin]

Hello!

On Fri, Mar 12, 2010 at 08:15:36PM +0300, Kirill A. Korinskiy wrote:

> At Fri, 12 Mar 2010 19:27:41 +0300,
> Maxim Dounin <mdounin at mdounin.ru> wrote:
> > 
> > Она, на самом деле, хорошая, годная.  И error_page 404 - на самом 
> > деле лучше, чем тот же try_files, ибо не имеет race'ов.
> > 
> 
> try_files это отдельная и сильно больная для меня песня. Внятного объяснения зачем я все
> еще не смог для себя вынести.

Зачем - понятно.  Чтобы if'ы не писали.  Вот if'ы - действительно 
больная тема.

[...]

> > > Защищаться от циклов глупо. Сделал человек цикл, значит сам дурак или ты можешь показать
> > > пример как сделать неявный цикл?
> > 
> > Защищаться от циклов - насущная необходимость, чтобы кривым 
> > конфигом нельзя было угробить сервер.
> > 
> 
> а давно дали в руки пользователей возможность писать конфиги? Т.е. либо пользователь
> грубит свой личный сревер, либо у вас бага в генераторе конфигов.

Да нет, он просто опечатался, ничего плохого не имел ввиду.  Не 
надо ему за это электричку.

> > А "неявный" - это кому как.  Я вот этот патчик не на пустом месте 
> > рисовал, а потому что ко мне пришли разбираться:
> > 
> > http://nginx.org/pipermail/nginx-devel/2010-January/000099.html
> > 
> > Понятно, что человек указавший несуществующий именованный location 
> > - сам себе злобный буратино.  Но приличный сервер не должен из-за 
> > этого кушать 100% cpu и переставать обрабатывать запросы, он 
> > ругаться должен.
> > 
> 
> ага, помню.
> 
> Я все-таки придерживаюсь позици Игоря тут: лучше выполнять то что хочет пользователь, а
> если он носастый, ну значит сам такой.

Как раз все нормальные места от циклов закрыты давно и прочно, 
перечитай код.

И, собственно, с чего начинался разговор: подобные недоработки в 
именованных location'ах есть.  И прежде чем расширять поддержку - 
хорошо бы их по возможности вычистить.

> > > Вот последние две вещи, лично мне, удобны. Т.е. когда надо чистить я делаю return +
> > > error_page, когда не надо чистить rewrite.
> > 
> > Внутренние редиректы - чистят, переходы в именованные location'ы - 
> > не чистят.  От метода вызова это не зависит.
> > 
> > И уже есть модули где это выходит боком.  Ибо они подбирают старый 
> > контекст и пытаются с ним работать, впадая в бесконечный цикл.  
> > Понятно что это в первую очередь проблема данных модулей, но 
> > нифига не понятно интуитивно.
> > 
> 
> Давай честно, nginx нифига не понятен интуитивно. Какие-то общие вещи, да, вполне. В
> деталях же творить полная вакханалия и равзрат.

Да нет на самом деле.  Большая часть вещей - очень даже понятна и 
логична.  Но есть нюансы. (c)

> > Тем более что семантика у переходов в named location'ы совсем 
> > даже не предполагает отличий в этом месте.  С другой стороны, 
> > чистить нельзя - ибо, как я уже писал, server rewrite phase по 
> > очевидным причинам не выполняется, и контексты поставленные 
> > там нужно сохранять.
> > 
> 
> Не знаю, слишком тонкий момент. Вообще момент с internal 
> redirect очень тонкий. Но раз есть двоякость, то увы.

С internal redirect'ами как раз всё проще пареной репы.  Поменять 
uri, всё очистить и выполнить заново.  А вот с именованными 
location'ами действительно всё не просто.  И я пока не понимаю как 
их логично вписать в ту же схему работы (или как переделать 
схему, чтобы они логично вписались).

Maxim Dounin