Enabling caching prevents previously published pages being unpublished by changing to draft

[gpoole]

Version

1.22.1

What did you expect to happen?

After changing a previously published page to draft again, I expected it to no longer be accessible on the site.

What actually happens?

The page is still accessible at the public URL. Looking at the response when accessing the unpublished page at its public URL, I see the fastcgi-cache header is always STALE. This is true even after waiting for over the default 30s cache duration.

If the cache is disabled, after changing a published page back to a draft, the public URL returns a 404 as expected.

The same issue looks to have been discussed in a previous support forum request but I think it's a bug as I would expect the caching config to work as expected by default in this case.

Steps to reproduce

1. Provision site with cache enabled with default settings e.g.

   wordpress_sites:
   example.com:
   # ...
   cache:
     enabled: true

2. Create and publish a page e.g. /test.
3. Access the page at example.com/test
4. Unpublish the page via "Switch to draft"
5. The page is still accessible at example.com/test

System info

Ubuntu 22.04

Log output

No response

Please confirm this isn't a support request.

Yes

[gpoole]

Would it make sense to change the standard NGINX config by adding any to fastcgi_cache_valid and adding a fastcgi_ignore_headers setting as mentioned in the support discussion I referenced earlier on this?

[gpoole]

Some alternative configurations that address this issue are also discussed on the NGINX issue tracker: https://trac.nginx.org/nginx/ticket/1233#comment:8

[swalkinshaw]

Nginx docs say:

If only caching time is specified then only 200, 301, and 302 responses are cached.

Setting it to any is risky because it can have the opposite problem where temporary error states could be cached for 30s.

I think it might be possible to skip the cache entirely if Cache-Control: no-cache exists. You could try adding this to wordpress-site.conf.j2:

map $upstream_http_cache_control $skip_cache {
    "~*no-cache" 1;
   # or
   # no-cache   1;
}

Would you be able to try that?