Inconsistency about cache's valid_sec

[Peng Fang]

Thaks for your reply.

I totally agree with you that modify valid_sec in header filters sound
buggy.

>From my side, this is a compromise for reality. Because not all upstream
servers are controlled by ourselves, especially for a 3rd CDN provider.
There are many customers who want to get highly customized expiration
settings, for example, 10 senconds for */a.jpg, 1 minite for */b.jpg, 10
minites for *.zip and so on,but they don't what to control thsese settings
by sending Cache-Control family headers. So we have implemented a delicate
logic in header filters supportting these requirements for every request.

Since it does not meet the standards, there is indeed no reson for you to
change the existed code logic. We coud totaly ignore and hide cache-control
family headers for these customuers, and keep on setting valid_sec in
header filters.

Woud you mind giving some advices for this kind of scenario? Thanks very
much.

2017-07-19 20:34 GMT+08:00 Maxim Dounin <mdounin at mdounin.ru>:

> Hello!
>
> On Wed, Jul 19, 2017 at 01:18:47PM +0800, Peng Fang wrote:
>
> > Hello, Maxim and other developers,
> >
> > In the latest official release, ngx_http_file_cache_set_header will be
> > called in ngx_http_upstream_send_response to realy set a cached file's
> > valid_sec.
> > before calling ngx_http_file_cache_set_header, there will be a chance
> for
> > user defined modules to change the valid_sec in their header filter
> > hooks,no matter what the value is set by
> > Cache-Control/Expires/X-Accel-Expires previously.
> >
> > And that's reasonable.
> >
> > When a cached file is expired, that logic will work fine too.
> >
> > Inconsistency happens, however, when proxy_cache_revalidate
> > <http://nginx.org/en/docs/http/ngx_http_proxy_module.
> html#proxy_cache_revalidate>
> > is enabled. when we enable proxy_cache_revalidate
> > <http://nginx.org/en/docs/http/ngx_http_proxy_module.
> html#proxy_cache_revalidate>,
> > ngx_http_file_cache_update_header will be called in
> > ngx_http_upstream_test_next. And in ngx_http_upstream_test_next, there is
> > no chance for user defined modules to change the valid_sec finally in
> their
> > header filter hooks. Because before calling ngx_http_upstream_cache_send
> in
> > ngx_http_upstream_test_next, valid_sec will be cached firstly, and set
> to a
> > cached file after calling ngx_http_upstream_cache_send and
> > ngx_http_file_cache_update_header.
> >
> > If we get valid_sec after ngx_http_upstream_cache_send in
> > ngx_http_upstream_test_next, user defined module's modification of
> > valid_sec will take effect.And the consistency will be kept.
> >
> > I don't konw if i missed something, so what do you think about this
> > situation?
>
> Trying to modify valid_sec from header filters looks like a bug to
> me.  It will expectedly lead to a wrong result in multiple cases,
> including the one you've described.  Don't do that.
>
> And no, the proposed solution won't work.  The goal of the code is
> to use cache validity as calculated based on the 304 response
> returned if it is available.  After ngx_http_upstream_cache_send()
> valid_sec will be based on the original cached response, and can
> be different.
>
> --
> Maxim Dounin
> http://nginx.org/
> _______________________________________________
> nginx-devel mailing list
> nginx-devel at nginx.org
> http://mailman.nginx.org/mailman/listinfo/nginx-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mailman.nginx.org/pipermail/nginx-devel/attachments/20170720/6d852c70/attachment-0001.html>