ПРОЕКТЫ 


  АРХИВ 


Apache-Talk @lexa.ru 

Inet-Admins @info.east.ru 

Filmscanners @halftone.co.uk 

Security-alerts @yandex-team.ru 

nginx-ru @sysoev.ru 


  СТАТЬИ 


  ПЕРСОНАЛЬНОЕ 


  ПРОГРАММЫ 



ПИШИТЕ
ПИСЬМА












     АРХИВ :: nginx-ru
Nginx-ru mailing list archive (nginx-ru@sysoev.ru)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: proxy_no_cache / proxy_cache_bypass



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 нужно будет выводить предупреждение
о изменении директивы.


-- 
Игорь Сысоев
http://sysoev.ru

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


 




Copyright © Lexa Software, 1996-2009.