Responses with "no-cache" or "max-age=0" should be cached

[geoff.addepar.com@…]

I know the summary sounds contradictory, but I believe that caching these responses is allowed, when revalidation is enabled. These responses would always need to be revalidated.

Here's the relevant part of the HTTP spec:

no-cache
       If the no-cache directive does not specify a field-name, then a
      cache MUST NOT use the response to satisfy a subsequent request
      without successful revalidation with the origin server. This
      allows an origin server to prevent caching even by caches that
      have been configured to return stale responses to client requests.

So, if "no-cache" is present, then nginx is allowed to cache the response, but must treat the cache entry as if it has already expired. The next lookup requires revalidation. I believe that "max-age=0" or "s-maxage=0" should be treated the same way, but I don't have a specific reference to the spec to justify my opinion.

We have an upstream server that is capable of returning 304 Not Modified much more quickly than it can generate the response body for a 200. We want to be able to use nginx's caching abilities to store the response body (especially to share that response body between users), but we also want to revalidate with the upstream server on every request. Right now we're working around this with "max-age=1" so that things expire quickly, but technically we want them to expire right away.

Also see "Pattern 2" on the first hit when searching "HTTP Cache Best Practices".
​https://jakearchibald.com/2016/caching-best-practices/

[micah.hainline@…]

Any update on this? This feels like a very legitimate problem. I have a server sending the following:

Cache-Control: max-age=0, public, must-revalidate;
ETag: W/"somestring"

And I expected it to cache that response when acting properly according to spec, and revalidate it with the server when it was called again. Any validation that of what's being said here, or a workaround if this problem still hasn't been fixed in the latest version?

[Maxim Dounin]

Historically, nginx does not cache responses with "max-age=0", as well as responses with Expires in the past, as such responses are effectively stale and cannot be used to respond to future requests.

Since ​proxy_cache_revalidate support was added, there are might be some valid use cases when caching such responses might be beneficial with proxy_cache_revalidate enabled. This probably needs further investigation.

Just for the record, one of the first discussions can be seen ​in this thread (in Russian).

If you want to use proxy_cache_revalidate to revalidate responses immediately, a readily available workaround is to control caching with the X-Accel-Expires: @0 header instead.

[micah.hainline@…]

Trying the following didn't work.

Cache-Control: max-age=0, public, must-revalidate;
ETag: W/"somestring"
X-Accel-Expires: @0

I'm assuming that max-age is still being used to determine that nginx will not cache in this case. We could change max-age=1 or some other value, but that would be counter to the spec and break other caches. Would that be the recommended workaround for this though?

[Maxim Dounin]

X-Accel-Expires: @0

My bad, should be X-Accel-Expires: @1 (which is essentially 1 second after the epoch), as plain zero will be handled as "no expiration time set" elsewhere and no caching will happen.

Additionally, this should be either before the Cache-Control header to make sure nginx wont't disable caching due to max-age=0, or the Cache-Control header should be explicitly ignored with ​proxy_ignore_headers.

[mczotter.b2international.com@…]

Hi All,

May I ask what's the status of this issue? This is really something we would like to get implemented as described in the HTTP standard.

Our use case if that helps:

Our backend service is a Git-like revision-controlled resource server, each resource has multiple versions stored in the database and users are able to access all or some of them (through fine-grained authorization, not RBAC, true per resource access-control). The backend service is responsible for calculating the visible set of resources and their contents when serving a request. We would like to be able to use HTTP caching directives to let a proxy server cache responses for more than one user, forming a shared cache and reducing response times even further. The problem is that the server must revalidate whether the user still have access not just to the system but to the resource as well and also must revalidate whether the resource revision is still the one that's the latest version. It is also possible to access versioned and timestamped data which effectively can be cached forever but even then access should be checked. The best possible way of doing this is with the s-maxage=0 or no-cache Cache-Control header value, which would enable the proxy server to cache the content, but when accessing the cached content again due to the expiration revalidation must be performed.

What we were able to achieve is using 1 second expiration with the s-maxage=1, but unfortunately there is no way of telling NGINX to force revalidate in all cases (if there is a config for that please share it with us) so due to the nature of the shared cache users are able to access to the shared content even if they don't have access in our authorization system (which is data leakage and a security issue).

I hope this makes sense.

Regards,
Mark