Nginx-ru mailing list archive (nginx-ru@sysoev.ru)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: limit_req_zone, переменный rate
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@xxxxxxxxxx> 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
_______________________________________________
nginx-ru mailing list
nginx-ru@xxxxxxxxx
http://nginx.org/mailman/listinfo/nginx-ru
|