Not working for both dynamic and static pages

Hi @wordy22,
Yes, you have guessed correctly. It’s because of your messy cache-control header. It is supposed to be the exact same value as you see in x-wp-cf-super-cache-cache-control and you can clearly see they are not the same.

It is impossible for me to tell who is adding that messy cache control, it could be some plugin you might have, it could be your server rules. It’s really hard to say. It’s better to contact your host about it as they can simply search a Unix server at the server level for the exact string private, proxy-revalidate, s-maxage=0, max-age=172800 and see from where it is coming from. Or at least find it better as they can perform the server-level search.

Otherwise, you have to turn off other plugins & mu-plugins to confirm they are not doing it and whether or not it is happening at the server level.

Hi Saumya,
Thank you for such a quick reply.

I contacted our host and they responded…
—
This is associated with the dynamic caching on the server.
I disabled it by adding the following header in the .htaccess file:
Header set Cache-Control “no-cache”
—

They added Cache-Control “no-cache” to the first line of .htaccess
Unfortunately, this didn’t solve the issue.

Now the response header related to cache is…
cache-control: no-cache
and…
server: nginx
vary: Accept-Encoding
x-cache-enabled: False
x-httpd-modphp: 1
x-proxy-cache: MISS
x-proxy-cache-info: W NC:000000 UP:SKIP_CACHE_NO_CACHE
x-wp-cf-super-cache: cache
x-wp-cf-super-cache-active: 1
x-wp-cf-super-cache-cache-control: s-maxage=31536000, max-age=60
x-wp-cf-super-cache-cookies-bypass: swfpc-feature-not-enabled

Is there another command I could add to .htaccess or some other option entirely that could solve this?

Hi @wordy22,
The plugin already adds the needed htaccess rule automatically. That rule you added simply just caused more issue. Try removing that htaccess you added and just try with the htaccess added by the plugin itself. If that doesn’t work, then the only option that remains for you is to enable the worker mode (under cache tab) unless your host removes that cache control that they add.

Hi Saumya,
I contacted our host and they replied that the original header in question is inserted by Cloudflare.

Here is their reply…
————————————–
Checked further and find that the headers are enforced by Cloudflare. These are the cache-control headers when accessing the domain normally, passing through the Cloudflare Server –

cache-control: private, proxy-revalidate, s-maxage=0, max-age=172800
x-wp-cf-super-cache-cache-control: s-maxage=31536000, max-age=60

And then the same when modifying my hosts file to bypass Cloudflare –

cache-control: s-maxage=31536000, max-age=60, max-age=172800
x-wp-cf-super-cache-cache-control: s-maxage=31536000, max-age=60
————————————–

So they are saying the issue lies with Cloudflare.

Would you know how I can get Cloudflare to stop adding the conflicting cache-control line?

Hi @wordy22,
That is wired I have never seen CF adding cache-control header. Can you please login to your CF dashboard, go to the Caching tab, and then under configuration, Browser Cache TTL is set to Respect Header? Screenshot: https://i.imgur.com/lorRPDR.png

Something fishy is happening in your case as when you said:

And then the same when modifying my hosts file to bypass Cloudflare –

cache-control: s-maxage=31536000, max-age=60, max-age=172800
x-wp-cf-super-cache-cache-control: s-maxage=31536000, max-age=60

You can clearly the the cache-control: s-maxage=31536000, max-age=60, max-age=172800 is basically the amalgamation of the cache control getting added by this plugin i.e. s-maxage=31536000, max-age=60 and max-age=172800 which is added by your server I gess.