ПРОЕКТЫ 


  АРХИВ 


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



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, 
даже если заголовки кеширование разрешают.

Maxim Dounin

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


 




Copyright © Lexa Software, 1996-2009.