No revalidation when using stale-while-revalidate
Maxim Dounin
mdounin at mdounin.ru
Fri Jul 24 02:33:48 UTC 2020
Hello!
On Thu, Jul 23, 2020 at 08:06:36PM +0200, Adam Volek wrote:
> We're running into some strange behaviour with the
> stale-while-revalidate extension of the cache-control header
> when using nginx as a reverse proxy. When
> there is a stale response in the cache with nonzero
> stale-while-revalidate time, nginx attempts revalidation but
> seems to ignore the upstream answer if it
> has specific status code, such as 404 or 500, and server a stale
> response to the client. Other response codes such as 200 or 410
> don't trigger this
> behaviour. Is this intended, and if so, is there a way to
> configure nginx to treat 404 as any other response?
As long as the response returned isn't cacheable (either
as specified in the response Cache-Control / Expires
headers, or per proxy_cache_valid), nginx won't put
the response into cache and will continue serving previously
cached response till stale-while-revalidate timeout expires.
Most likely "specific status code" in your tests in fact means
responses returned by your upstream server without Cache-Control
headers, and hence not cached by nginx.
> I understand that this behaviour might be desirable in some
> situations (especially for the responses with 5xx status codes),
> but in our case, if the
> upstream return a 404 response, we would want the cache to start
> returning it as well as soon as the revalidation is finished.
As long as the above analysis is correct, the solution is simple:
make sure responses you want nginx to cache are cacheable, that
is, make sure appropriate headers are present or configure
proxy_cache_valid (http://nginx.org/r/proxy_cache_valid).
--
Maxim Dounin
http://mdounin.ru/
More information about the nginx
mailing list