I noticed that the nginx http proxy module by default does nothing with
the
Cache-Control request header that is sent by browsers.
Most browsers (I tested Crome and Firefox, but from my online research
it
showed that even Internet Explorer has the same behaviour) send a
Cache-Control: no-cache header when the page requested is with Ctrl-F5
(as
opposed to a normal F5 or page hit). I would like to configure my nginx
caching proxy to take this request as an instruction to invalidate the
cache, send a request to an upstream server, and send and cache that
response.
Note that I’m NOT talking about the Cache-Control header sent from
upstream
webservers to the proxy. It’s the Cache-Control request headers, not the
response header.
Is there a configuration option that I’ve missed? I spent quite some
time
reading the documentation. Sadly the search terms that I can come up
with
(cache-control, proxy, etc) are too generic for what I want to express.
On Thu, Mar 13, 2014 at 12:20:41PM -0400, bcx wrote:
Note that I’m NOT talking about the Cache-Control header sent from upstream
webservers to the proxy. It’s the Cache-Control request headers, not the
response header.
Is there a configuration option that I’ve missed? I spent quite some time
reading the documentation. Sadly the search terms that I can come up with
(cache-control, proxy, etc) are too generic for what I want to express.
The proxy_cache_bypass directive can be used for what you are
looking for, see docs here:
Thank you for your suggestion. I understand about the DoS issue.
proxy_cache_bypass indeed is the solution. Documentation was not clear
about
it, but the result is written to cache. The cache is only bypassed in
the
lookup fase, not in the write back fase.
I worked out this bit of configuration. The added header is very useful
while testing, I’d remove it in production.
location / {
if ($http_cache_control = “no-cache”) {
set $ctrl_Ffive_ed “yes”;
}
proxy_cache_bypass $ctrl_Ffive_ed;
add_header X-cache-bypass $ctrl_Ffive_ed;
On Thu, Mar 13, 2014 at 06:34:52PM -0400, bcx wrote:
Thank you for your suggestion. I understand about the DoS issue.
proxy_cache_bypass indeed is the solution. Documentation was not clear about
it, but the result is written to cache. The cache is only bypassed in the
lookup fase, not in the write back fase.
Documentation explicitly says that proxy_cache_bypass “defines
conditions under which the response will not be taken from a
cache”. There is proxy_no_cache to control saving responses to
a cache.
I worked out this bit of configuration. The added header is very useful
while testing, I’d remove it in production.
location / {
if ($http_cache_control = “no-cache”) {
set $ctrl_Ffive_ed “yes”;
}
proxy_cache_bypass $ctrl_Ffive_ed;
add_header X-cache-bypass $ctrl_Ffive_ed;
Just a side note:
Use of map{} for such things is usually a better idea, though it
probably doesn’t matter for testing.