Re: proxy_no_cache / proxy_cache_bypass

[Maxim Dounin <mdounin@xxxxxxxxxx>]

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".  Что будет логичнее и гибкости даст 
существенно больше.

Maxim Dounin

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