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

[Богун Дмитрий <vugluskr@xxxxxxxxxxxxxxx>]

В сообщении от Среда, 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@xxxxxxxxx
http://nginx.org/mailman/listinfo/nginx-ru