Hello!

On Thu, Jul 08, 2010 at 07:14:57PM +0400, Igor Sysoev wrote:

> On Thu, Jul 08, 2010 at 06:23:39PM +0400, Maxim Dounin wrote:
>
> > Hello!
> >
> > On Thu, Jul 08, 2010 at 02:48:41PM +0400, Igor Sysoev wrote:
> >
> > > On Thu, Jul 08, 2010 at 02:37:01PM +0400, Maxim Dounin wrote:
> > >
> > > > Hello!
> > > >
> > > > On Thu, Jul 08, 2010 at 01:12:58PM +0400, Igor Sysoev wrote:
> > > >
> > > > > На данный момент proxy/fastcgi/uwsgi/scgi_no_cache игнорируют ответ
> > > > > в кэше и идут к бэкенду. Но полученный ответ может быть закэширован,
> > > > > если бэкенд это явно разрешил с помощью X-Accel-Expres, Expires или
> > > > > Cache-Control. proxy_cache_valid при этом не учитываются.
> > > > >
> > > > > Есть идея ввести proxy_cache_bypass, при которой ответ в кэше игнорируется,
> > > > > но полученный ответ может быть закэширован в зависимости от разрешения
> > > > > бэкнда _И_ директив proxy_cache_valid.
> > > > >
> > > > > Какое поведение в этом случае оставить для proxy_no_cache - не понятно:
> > > > > то ли вообще запретить кэшировать ответ, то ли оставить как есть.
> > > >
> > > > По хорошему, нужны возможности гибкого управления в двух местах:
> > > >
> > > > 1. Берём ли мы ответ из кеша. Сейчас это делается через
> > > > proxy_no_cache, что по моим ощущениям вполне достаточно.
> > > >
> > > > 2. Кладём ли мы ответ в кеш. Сейчас можно только либо полностью
> > > > доверится бекенду, либо совсем не доверять и использовать
> > > > proxy_cache_valid.
> > > >
> > > > Если я правильно понял предлагаемую семантику proxy_cache_bypass,
> > > > то предлагается управлять сразу и (1) и (2). Мне не видится это
> > > > хорошим решением.
> > > >
> > > > Вот, например, use case: файлы лежат на бекенде и большие, нужно
> > > > поддерживать Range к бекендам, при этом хочется кеширование для
> > > > полностью скаченных файлов. Решение - брать ответы из кеша в если
> > > > они там есть, если нет - отправлять запрос на бекенд вместе с
> > > > заголовком Range, и не кешировать 206 ответы. Сейчас это можно
> > > > сделать только отказавшись от учёта Cache-Control/Expires. И
> > > > proxy_cache_bypass в решении этой проблемы никак не поможет.
> > > >
> > > > IMHO, правильно увеличивать именно возможности управления (2).
> > > >
> > > > Что касается proxy_cache_bypass, то аналогичное поведение
> > > > может быть достигнуто с помощью proxy_no_cache и директивы,
> > > > включающей семантику "в зависимости от разрешения бэкнда _И_
> > > > директив proxy_cache_valid". Что будет логичнее и гибкости даст
> > > > существенно больше.
> > >
> > > Логично, тогда можно раздедить так: proxy_cache_bypass определяет,
> > > брать ли ответ из кэша, а proxy_no_cache - класть ли ответ в кэш,
> > > если он был в состоянии bypass.
> >
> > Нет-нет-нет. Не надо завязыватся на "если он был в состоянии
> > bypass".
> >
> > Посмотри use case ещё раз - там *не нужно* пропускать кеш. Если
> > ответ есть в кеше - его просто нужно отдать. А вот если там
> > ответа не нашлось - то нужно *не сохранять* в кеш ответы с 206,
> > даже если заголовки кеширование разрешают.
>
> Да, наверное, это имеет смысл. Тогда первое время при использовании
> proxy_no_cache без proxy_cache_bypass нужно будет выводить предупреждение
> о изменении директивы.

Мне не нравится идея изменять семантику proxy_no_cache (даже с
учётом её недавнего появления), впрочем и сама директива не
нравится - и семантика по названию не ясна, и из общего ряда
proxy_cache_* выбивается. Лучше уж прибить чем менять.

Для семантики "не отдавать ответ из кеша" определённо лучше будет
proxy_cache_bypass.

Для "не класть в кеш" - мне пожалуй больше всего нравится вариант
proxy_cache_noupdate.

Но в принципе всё равно каким цветом покрасить, да.

Maxim Dounin

_______________________________________________
nginx-ru mailing list
nginx-ru@nginx.org
http://nginx.org/mailman/listinfo/nginx-ru