<div dir="ltr"><div style="white-space:pre-wrap;line-height:1.75;font-size:14px">Thaks for your reply.</div><div style="white-space:pre-wrap;line-height:1.75;font-size:14px"><br></div><div style="white-space:pre-wrap;line-height:1.75;font-size:14px">I totally agree with you that modify valid_sec in header filters sound buggy.</div><div style="white-space:pre-wrap;line-height:1.75;font-size:14px"><br></div><div style="white-space:pre-wrap;line-height:1.75;font-size:14px">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 <span style="font-family:Arial;color:rgb(67,67,67);background-color:rgb(252,252,254)">implemented a delicate logic in header filters supportting these requirements for every request.</span></div><div style="white-space:pre-wrap;line-height:1.75;font-size:14px"><br></div><div style="white-space:pre-wrap;line-height:1.75;font-size:14px"><span style="font-family:Arial;color:rgb(67,67,67);background-color:rgb(252,252,254)">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.</span></div><div style="white-space:pre-wrap;line-height:1.75;font-size:14px"><br></div><div style="white-space:pre-wrap;line-height:1.75;font-size:14px"><span style="font-family:Arial;color:rgb(67,67,67);background-color:rgb(252,252,254)"> Woud you mind giving some advices for this kind of scenario? Thanks very much.</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">2017-07-19 20:34 GMT+08:00 Maxim Dounin <span dir="ltr"><<a href="mailto:mdounin@mdounin.ru" target="_blank">mdounin@mdounin.ru</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello!<br>
<span class=""><br>
On Wed, Jul 19, 2017 at 01:18:47PM +0800, Peng Fang wrote:<br>
<br>
> Hello, Maxim and other developers,<br>
><br>
> In the latest official release, ngx_http_file_cache_set_header will be<br>
> called in ngx_http_upstream_send_<wbr>response to realy set a cached file's<br>
> valid_sec.<br>
> before calling ngx_http_file_cache_set_<wbr>header, there will be a chance for<br>
> user defined modules to change the valid_sec in their header filter<br>
> hooks,no matter what the value is set by<br>
> Cache-Control/Expires/X-Accel-<wbr>Expires previously.<br>
><br>
> And that's reasonable.<br>
><br>
> When a cached file is expired, that logic will work fine too.<br>
><br>
> Inconsistency happens, however, when proxy_cache_revalidate<br>
</span>> <<a href="http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_cache_revalidate" rel="noreferrer" target="_blank">http://nginx.org/en/docs/<wbr>http/ngx_http_proxy_module.<wbr>html#proxy_cache_revalidate</a>><br>
<span class="">> is enabled. when we enable proxy_cache_revalidate<br>
</span>> <<a href="http://nginx.org/en/docs/http/ngx_http_proxy_module.html#proxy_cache_revalidate" rel="noreferrer" target="_blank">http://nginx.org/en/docs/<wbr>http/ngx_http_proxy_module.<wbr>html#proxy_cache_revalidate</a>>,<br>
<span class="">> ngx_http_file_cache_update_<wbr>header will be called in<br>
> ngx_http_upstream_test_next. And in ngx_http_upstream_test_next, there is<br>
> no chance for user defined modules to change the valid_sec finally in their<br>
> header filter hooks. Because before calling ngx_http_upstream_cache_send in<br>
> ngx_http_upstream_test_next, valid_sec will be cached firstly, and set to a<br>
> cached file after calling ngx_http_upstream_cache_send and<br>
> ngx_http_file_cache_update_<wbr>header.<br>
><br>
> If we get valid_sec after ngx_http_upstream_cache_send in<br>
> ngx_http_upstream_test_next, user defined module's modification of<br>
> valid_sec will take effect.And the consistency will be kept.<br>
><br>
> I don't konw if i missed something, so what do you think about this<br>
> situation?<br>
<br>
</span>Trying to modify valid_sec from header filters looks like a bug to<br>
me.  It will expectedly lead to a wrong result in multiple cases,<br>
including the one you've described.  Don't do that.<br>
<br>
And no, the proposed solution won't work.  The goal of the code is<br>
to use cache validity as calculated based on the 304 response<br>
returned if it is available.  After ngx_http_upstream_cache_send()<br>
valid_sec will be based on the original cached response, and can<br>
be different.<br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Maxim Dounin<br>
<a href="http://nginx.org/" rel="noreferrer" target="_blank">http://nginx.org/</a><br>
______________________________<wbr>_________________<br>
nginx-devel mailing list<br>
<a href="mailto:nginx-devel@nginx.org">nginx-devel@nginx.org</a><br>
<a href="http://mailman.nginx.org/mailman/listinfo/nginx-devel" rel="noreferrer" target="_blank">http://mailman.nginx.org/<wbr>mailman/listinfo/nginx-devel</a><br>
</font></span></blockquote></div><br></div>