NGINX Not Honoring proxy_cache_background_update with Cache-Control: stale-while-revalidate Header
|Reported by:||Ian Stephens||Owned by:|
|Keywords:||background update cache control stale-while-revalidate||Cc:|
|nginx -V:||nginx version: nginx/1.15.9|
We are running NGINX in front of our backend server.
We are attempting to enable the proxy_cache_background_update feature to allow NGINX to async updates to the cache and serve STALE content while it does this.
However, we are noticing that it still delivers STALE content slowly as if it's not serving from the cache. The time it takes to deliver a response to the client after an item expires is very slow and clearly not served from cache - you can tell it's going to the backend server, getting an update and serving the client in the same request.
Here is our configuration from NGINX:
proxy_ignore_headers Expires; proxy_cache_background_update on;
Our backend server is delivering the following headers:
HTTP/1.1 200 OK Date: Thu, 28 Feb 2019 21:07:09 GMT Server: Apache Cache-Control: max-age=1800, stale-while-revalidate=604800 Content-Type: text/html; charset=UTF-8
When attempting an expired page fetch we do correctly notice a STALE response in the header:
However, when providing this response it is very slow as if it's contacted the backend server and done it in real-time.
$ nginx -v nginx version: nginx/1.15.9
It seems that nginx is honoring serving stale content (as we have tested) but it also updates the cache from the backend on the same request/thread thus causing the slow response time to the client. I.e. it seems to be totally ignoring the proxy_cache_background_update on; directive and not updating in the background on a separate subrequest (async).
We have also tried with
However, the same behavior happens. As far as I'm aware, there is also no need to use proxy_cache_use_stale updating; when the backend sets a Cache Control: stale-while-revalidate header. The issue seems to be that it honors serving STALE content but it is also updating the cache on the same thread as the request comes in - i.e. it's simply ignoring proxy_cache_background_update on;