The difference is about 2 days, so it looks like
proxy_ignore_headers works as it should.
I suppose previously you’ve looked at files cached without
proxy_ignore_headers in config. Note that changing config isn’t
enough to get longer cache valid times for already cached
responses, since validity time is calculated while obtaining
response from a backend. A response have to be recached with the
new settings.
A side note: you may want to hide or change Expires header to
make sure clients will be able to cache responses. This may be
done either with proxy_hide_header or with “expires” directive.
No, that’s proxy_ignore_headers, not proxy_hide_header.
proxy_cache_valid 200 302 600h;
proxy_cache_valid any 90m;
But as you can see, you can find expire, cache-control headers in proxy
repsonse, and also in headers of stored cache files on disk. With values
from upstream server, not those set in config.
What comes from upstream is stored on disk. That’s expected.
proxy_ignore_headers determines which of upstream headers or
proxy_cache_valid is used by nginx to decide for how long nginx will
cache the response.
Separate from that, you can use “proxy_hide_header” to tell nginx not to
send some headers that came from upstream, to the client.
Separate from that (mostly), you can use “expires” to tell nginx how to
set Expires: and Cache-Control: headers in the response to the client.
“(mostly)” is there because nginx will only send a single Expires
header,
so if you use “expires” to set one, then the one from upstream will not
go to the client, even if it isn’t in “proxy_hide_header”.
I’m not sure now those times from my previous response, but whatever i
do (delete cached files from disk, restart nginx, wait 10 minutes to
expire files cached on disk), nginx is always returning in response
cache-control and expire in 600 sec - taking this value from upstream
server, not from the config file.
That is as expected, since you have no other value in the config file
to send in the response, and you have nothing in the config file to tell
nginx not to send what came from upstream.
Also, file is stored on disk for 600s,
after this time i can see in logs that nginx is downloading again file
from upstream server. Nginx should cache files for 600h in current
config, but i’ve also tried before other values, like 6h or 6d etc.
That observation, I don’t understand.
You can examine the first few bytes of the on-disk cache file to see
when nginx thinks that it will become stale:
od -t dL $cache_file | head -n 1
The second and fourth numbers there are valid-until- and fetched-at-
timestamps, respectively. So if they are only 600 apart, then something
unexpected (to me) is happening.
When I use configuration like
proxy_cache_valid 200 302 600h;
proxy_cache_valid any 90m;
in 1.1.11, I see them being the expected 2160000 (seconds, = 600 hours)
apart for a http 200 response.
On Wed, Jan 04, 2012 at 10:26:05PM +0000, Francis D. wrote:
On Wed, Jan 04, 2012 at 03:12:10PM -0500, piotr wrote:
Hi there,
One more thing on the final “600s”…
Also, file is stored on disk for 600s,
after this time i can see in logs that nginx is downloading again file
from upstream server. Nginx should cache files for 600h in current
config, but i’ve also tried before other values, like 6h or 6d etc.
That observation, I don’t understand.
You don’t specify “inactive” in your proxy_cache_path directive, so it
defaults to 10 minutes.
If you see one new request per url every 11 minutes, then it is expected
that nginx will re-fetch from upstream each time.
If you see a new request every 9 minutes, then nginx should not need to
re-fetch from upstream.
But as you can see, you can find expire, cache-control headers in proxy
repsonse, and also in headers of stored cache files on disk. With values
from upstream server, not those set in config.
I’m not sure now those times from my previous response, but whatever i
do (delete cached files from disk, restart nginx, wait 10 minutes to
expire files cached on disk), nginx is always returning in response
cache-control and expire in 600 sec - taking this value from upstream
server, not from the config file. Also, file is stored on disk for 600s,
after this time i can see in logs that nginx is downloading again file
from upstream server. Nginx should cache files for 600h in current
config, but i’ve also tried before other values, like 6h or 6d etc.
Yes, i’ve missed this “inactive” param - unfortunately expire time from
upstream server was the same as default inactive value, with was
misleading for me.
On Wed, Jan 04, 2012 at 03:12:10PM -0500, piotr wrote:
But as you can see, you can find expire, cache-control headers in proxy
repsonse, and also in headers of stored cache files on disk. With values
from upstream server, not those set in config.
You don’t hide the headers, and don’t set headers in config. The
proxy_ignore_headers instruct nginx to ignore headers in question
(i.e. don’t set/limit cache validity time as stored in cache
metadata based on these headers). The proxy_cache_valid
directives set cache validity times. None of these directives
hide or modify headers in question.
To hide headers, you have to use the proxy_hide_header directive
(as already suggested in previous message), see here for details:
I’m not sure now those times from my previous response, but whatever i
do (delete cached files from disk, restart nginx, wait 10 minutes to
expire files cached on disk), nginx is always returning in response
cache-control and expire in 600 sec - taking this value from upstream
server, not from the config file. Also, file is stored on disk for 600s,
after this time i can see in logs that nginx is downloading again file
from upstream server. Nginx should cache files for 600h in current
config, but i’ve also tried before other values, like 6h or 6d etc.
Do you request the file in question with interval larger than 600
seconds, without any intermediate requests? It is expected to be
removed from cache as inactive one in such test, see desciption of
the “inactive” parameter of the “proxy_cache_path” directive here: