В сообщении от Среда, 18-авг-2010 03:56:59 автор Maxim Dounin написал:
> Hello!
>
> On Wed, Aug 18, 2010 at 01:31:13AM +0300, Богун Дмитрий wrote:
> > В сообщении от Среда, 18-авг-2010 00:10:09 автор Maxim Dounin написал:
> > > > Наставьте пожалуйста на путь истинный, моя это бага или nginx'a? Даже
> > > > если моя, nginx ведет себя весьма не хорошо.
> > >
> > > [...]
> > >
> > > > proxy_cache_key "$host$request_uri?$args";
> > >
> > > В /test3.php делается инклуд /test2.php, который в свою очередь
> > > достаётся из кеша по ключу, содержащему только $request_uri -
> > > оригинальный uri полученный от клиента, т.е. в данном случае
> > > /test3.php. В результате имеем бесконечный рекурсивный ssi.
> >
> > Вот оно как...
> >
> > > Защиты от рекурсии в ssi сейчас нет.
> >
> > А можно как-то защититься от подобного на уровне конфига? Потому как то
> > что выплюнут из php не находится под моим прямым контролем и если по
> > ошибке будет происходить такой фокус, будет весьма неприятно.
>
> Способов защититься на уровне конфига я не знаю. А патч про это я
> постил, по крайней мере для 0.8.*. Он, правда, не очень хороший,
> надо будет как-нибудь переделать на более прозрачную логику.
>
> > Раз есть проверка на internal, быть может есть и переменная, которая при
> > internal запросе имеет значение true а при внешнем запросе - false, тогда
> > при помощи нее можно идти мимо кеша в подобных.
>
> Переменной нет. Впрочем, даже если ходить мимо кеша - никто не
> помешает случайно вернуть include на самого себя. С тем же
> результатом на выходе.
Да, для определения подобной ситуации нужна уже не логическая переменная, а
счетчик вложенности. Но имея во внутренностях счетчик вложенности запросов,
наверное была бы и защита от рекурсии...

Но даже булевская переменная принимающая значение true на internal запросах
сильно бы помогла. Можно попросить создать такую переменную в будущих версиях
nginx?
_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://nginx.org/mailman/listinfo/nginx-ru