Re: Анонс: статья "Подводные камни при использовании кэширования в nginx"

[Sergey Shepelev]

2009/10/19 Peter A Leonov <gojpeg at gmail.com>:
> On 19.10.2009, at 23:26, Аверьянов Сергей <asv at pallant-mobile.ru> wrote:
>
>> On Mon, 19 Oct 2009 22:41:42 +0400, Dmitry Koterov <dmitry at koterov.ru>
>> wrote:
>>
>>> Было бы идеально, если бы скрипт, вставляемый по SSI, мог выставлять свои
>>> куки. Решило бы не только эту, но также еще и кучу других проблем.
>>>
>>> Однако, к сожалению, он это не может, я проверил.
>>
>> Если мне не изменяет память, фишка в том, что все хедеры уходят до того,
>> как начинают обрабатываться SSI-директивы.
>
> Их можно попросить задержаться ;)
>
>> Ну и по логике тоже не понятно. Допустим, есть 2 SSI директивы,
>> одна выставляет в некую куку значение Х, другая Y.
>> Выполняются директивы параллельно.
>> Результат в итоге малопредсказуем имхо.
>
> Это верно для многопоточных серверов, которые забывают друг о друге ;) nginx
> worker работает в один поток и может уложить две и более кук в заголовки
> ответа.

Это также верно для event-driven серверов, которые выполняют SSI
include с запросами на бекенды, поскольку порядок ответа бекендов не
известен.

А вот что здесь неверно, так это рассчитывать на порядок выполнения
запросов, без указания этого самого порядка.

Лучше поверните минус в ноль: если два SSI устанавливают одну куку,
значит точное значение куки не определено. И всё. Сам себе злобный
буратина. Не надо в разных подзапросах ставить одну куку.
В помощь, например, вот такая конструкция:

<!--# include virtual="/remote/body.php?argument=value"
allow_cookie="sessionid" -->

чётко задаёт какую куку может изменить конкретно этот подзапрос. Это
всё ещё не решает проблемы двух конкурентных подзапросов, но их просто
не надо писать два на одну куку.

>
> В принципе, из этого может получиться несложная и интересная задачка на
> изучение модуля SSI :)
>
>> --
>> С уважением,
>> Сергей Аверьянов
>
> --
> С уважением,
> Петр Леонов