On Sep 24, 2015, at 9:16 PM, CJ Ess <[hidden email]> wrote:
> I'm experimenting with fastcgi caching - I've added $upstream_cache_status to the access log, and I can see that periodically there will be a small cluster of EXPIRED requests for an object.
> Does EXPIRED imply that the object was fetched from origin each time?
Correct, but see below.
> ..or that the requests were queued while a request to origin was made?
For requests queued with proxy_cache_lock, this would be HIT,
i.e. after a resource was eventually fetched from origin, queued
requests to the same resource are served from now populated cache.
> ..or that the expired object was served while an update was fetched?
That would be UPDATING.
> ..or something else?
> I can understand any of those cases, I just want to be able to explain how many origin fetches were actually done.
Depending on fastcgi_cache_revalidate setting, EXPIRED is either
simply due to an outdated cached response, or a failed revalidation.
In either way, a full response is served from an upstream (origin) server.