We are using Varnish cache 6.2 to sit in front of our WebAPI backend. The backend is sending a cache-control header back on certain requests, for things that we can cache for a bit longer.
However - should the backend go down, and stay down, we send stale-while-revalidate of an hour.
So a typical cache-control response header from our backend looks like:
public, max-age=30, stale-while-revalidate=3600
In our Varnish VCL we have added a routine that stops background fetch on certain errors. This is to stop the bad response from the backend from entering the cache:
sub vcl_backend_response {
if (beresp.status == 500 || beresp.status == 502 || beresp.status == 503 || beresp.status == 504)
{
if (bereq.is_bgfetch)
{
return (abandon);
}
set beresp.ttl = 1s;
}
}
The problem we are facing is simple - Varnish does not update the item in the cache after Max-Age expires, even though the backend is available. (And changes have occurred to the response) We have seen issues where the responding "Age" header from Varnish exceeds 200s, with the wrong response. We have also seen cases where the "Age" header is 1-3s, which would indicate a background fetch (or normal fetch) has occurred.
This happens often enough that we notice it - but not on every request.
I have tried a simple "pass", such as the following in Varnish:
sub vcl_recv {
return(pass);
}
However, this appeared to have no effect.
Could there be anything else with Varnish setup that could cause the situation above?
EDIT, as per comment, this is a small thing we add to each sub that interacts with our request, to see what actually happened:
sub vcl_deliver {
if (obj.uncacheable) {
set req.http.x-cache = req.http.x-cache + " uncacheable" ;
} else {
set req.http.x-cache = req.http.x-cache + " cached" ;
}
set resp.http.x-cache = req.http.x-cache;
}
sub vcl_hit {
set req.http.x-cache = "hit";
}