LiteSpeed Cache prevents browsers to re-validate pages

Hi EveryOne!

I'm using OLS 1.7.16 with WordPress 6.1.1 and LiteSpeed Cache for WP. The problem is that whe I use LSCWP then pages are not re-validated by the browser and not updated.

I have to WP installations at my hosting. One is with SuperCache and it works perfectly with updating of the pages. And one with LSCWP and here I have a small problem.

As I can see using the developer tools in Chromium the problem is that a browser takes page from the blog that uses LSCWP until the max-age is ended or a user press F5.

I see the following in the headers:

    cache-control: public, max-age=604800
    x-litespeed-cache: hit
The page is in cache - that is very good and I use LSCWP exactly for this. But if I change a blog record then it is not updated in the browser (the cache at the server is re-generated). The browser takes the page from its local cache (disk, it is visible in the developers tools).

OLS doesn't include eTag for generated pages (but do this for all the static files, except cached dynamic files).

From the other side SuperCache works well. It provides the following header in the most cases cache-control: max-age=3, must-revalidate and the browser check the page before taking it from the local cache.

Blog page with LSCWP and with SuperCache

The server is the same but the virtual hosts are different. Browser cache in LSCWP is disabled:

What can be wrong? I'd like to make the dynamic cached pages to be re-validated before taken from the browser cache.
The browser cache is actually enabled on the server level due to OLS only recognizes rewrite rules, and it will only apply to the static files only. The "cache-control: max-age=3 " is not efficient, it's similar to no browser cache.
I'm not clear about updating the blog issue, please describe it more. Does the new content not updating in public or?
The browser cache is actually enabled on the server level due to OLS only recognizes rewrite rules, and it will only apply to the static files only. The "cache-control: max-age=3 " is not efficient, it's similar to no browser cache.
I'm not clear about updating the blog issue, please describe it more. Does the new content not updating in public or?
Exactly, the new content is placed but if I use a browser then (public, not private) I don't see the new content until I execute a refresh of a page. Browser always takes the page from its own cache and don't do validation of the page. That behaviour is valid for all Chromium browsers. Didn't check it with Mozilla's variants.

From my point of view the problem can be in two points:
1. Absence of etag for dynamic pages. In that case the browser is not able to compare the hash of the etags and decide to download the page again.
2. Absence of necessary headers according to cache settings. `max-age=3` is too low for a normal cache value - fully agree. But also `must-revalidate` can be a remedy. Also `no-cache` (or `max-age=0` can be an answer. Accroding to the specification `no-cache` doesn't prevent a browser to store the page in its cache. It requires re-validate the page during the next request of the page from the server (`no-store` prevents the browser form storing a page in its cache).

In the private mode the plugin provides correct values `cache-control: no-cache, must-revalidate, max-age=0`

As I understand the headers can be replaced at OLS level with a Context for dynamic pages. I've tried with no success (I think that I've missed some parameters). So will retry.

PS. I've noticed that behaviour when was evaluating OLS so since then I have two blogs with different caching plugins. Have plans to move completely to LS solutions. But need to fix all the rough corners :)
Last edited:
1. The etag gone issue usually happens due to the remove etag rule placed in the .htaccess file.
2. There's no cache-control header on the dynamic page, so I'm not sure why the browser cache is related.
curl -I
HTTP/2 200
content-type: text/html; charset=UTF-8
link: <>; rel=""
link: <>; rel="alternate"; type="application/json"
link: <>; rel=shortlink
vary: Accept-Encoding
server: LiteSpeed
strict-transport-security: max-age=63072000; includeSubDomains; preload
alt-svc: h3=":443"; ma=2592000, h3-29=":443"; ma=2592000, h3-Q050=":443"; ma=2592000, h3-Q046=":443"; ma=2592000, h3-Q043=":443"; ma=2592000, quic=":443"; ma=2592000; v="43,46"
x-litespeed-cache: hit
date: Mon, 23 Jan 2023 08:20:14 GMT
I've check this once more.

1. Regarding to eTag - there is no mentions of this in .htaccess I have for the site including WordPress site. Moreover if they were there they shouldn't be used by OLS because it works only with RewriteRule (according to the documentation). Anyway noticed some functions in WordPress that can generate eTags. But I don't see eTags for the dynamic pages not for LSCWP enabled site nor for SuperCache.
2. Now I don't see any cache-control at the dynamic pages o_O now. And they works well, if a page was changed at WP side the browser shows it.
3. I see only 200 responses. No 304. That is not good. as @LiteCache mentioned.

Actually I didn't do anything with the sites except two things:

a. Removed Expires Default at VirtualHost level and added other types:

b. Browser cache in LSCWP plugin:
It was turned off. But I turned it off a little bit more :)

I'd like to check Browser Cache option once more.
OK. Some more tests:

1. I've enabled Browser cache in LSCWP.
Nothing happened. I still receive 200 code, no `cache control` in headers. Pages are updated without their reload with F5. Purging all the cache didn't helped.
So, the behaviour is not changed.

2. Reboot OLS-server. Nothing changed. I still have only 200 code with no `cache control` in the headers at all.

3. Added Default Expires. Reboot OLS. The same behaviour. Everything works except 304 code.

4. Removed Expires By Type at OLS.
And here I got cache-control. But still no 304 code.


and here I have the problem behaviour when a page is updated at WP side, LSCWP cleared the cache but the browser takes the page from its own cache. Purging of the cache at LSCWP side doesn't help. Reload page helps to get the updated page.

So. There is something not correct:
a. `Browser Cache` options at LSCWP doesn't change the behaviour.
b. `Cache-control` appears only when all the types of content is marked with Expires at OLS-server.
c. Browser always receives only 200 code*.
d. Browser when receives `Cache-control` takes page from its own cache and don't do any type of validation.

What to do :) or To Do or Not To Do.

* I've checked the server logs. There are some 304 records of resources from the blog. Like CSS. I've reload pages a lot today and not 304 today.

PS. I also noticed that LSCWP shows the following:
  1. x-litespeed-cache:
  2. x-litespeed-cache-control:
  3. x-litespeed-tag:

Only when it misses the cache. If it hits no
  • x-litespeed-cache-control:

Last edited: