Re: рекурсивное исполнение ssi.

[Богун Дмитрий]

В сообщении от Среда, 18-авг-2010 10:13:29 автор Богун Дмитрий написал:
> В сообщении от Среда, 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?
Или можно "вывести" в переменную актуальный uri для текущего запроса, тогда 
$request_uri будет сохранять свое значение в подзапросах как и сейчас, а 
$request_uri_imm будет равен uri подзапроса в подзапросе и $request_uri в 
запросе верхнего уровня. Тогда по разнице значений в $request_uri и 
$request_uri_imm можно будет определять что мы выполняемся в подзапросе.

Но введя одну такую переменную может захотется иметь и еще некоторые другие 
переменные с актуальными значениями для текущего запроса.