LSCache Mediawiki Plugin

Balerion · Jan 27, 2024

Hi,

New to OLS, trying to see if I can figure out why I can't get LiteSpeed Cache to work with the Mediawiki plugin on an MW 1.31 install -- it feels like it's most of the way there, but I seem to be missing something.

check.lscache.io tells me that LSCache is supported, and I see headers like this:



HTTP/1.1 200 OK

x-powered-by: PHP/7.4.33

x-content-type-options: nosniff

pragma: no-cache

[B]x-litespeed-cache-control: public,max-age=864020[/B]

x-litespeed-tag: ...

content-type: text/html; charset=UTF-8

content-language: en

x-ua-compatible: IE=Edge

vary: Accept-Encoding, Cookie

last-modified: Sat, 27 Jan 2024 22:07:45 GMT

expires: Thu, 01 Jan 1970 00:00:00 GMT

cache-control: private, max-age=0, s-maxage=300

[B]x-litespeed-cache: miss[/B]

content-encoding: gzip

So, it reports a miss, no matter how often I reload. But I've checked the lscache directory, and it seems to be storing cached copies in a priv directory... but never pub (public?), for some reason, which may be why it's not returning hits. I'm very confused by it.

Here is my cache module setup on the server:



storagePath $SERVER_ROOT/cachedata

checkPrivateCache 0

checkPublicCache 1

maxCacheObjSize 10000000

maxStaleAge 200

qsCache 1

reqCookieCache 1

respCookieCache 1

ignoreReqCacheCtrl 1

ignoreRespCacheCtrl 1



enableCache 0

expireInSeconds 3600

enablePrivateCache 0

privateExpireInSeconds 3600

And here on the virtual host with the domain where the wiki is installed:



storagePath $VH_ROOT/lscache

CacheEngine on

CacheLookup on

CacheIgnoreCacheControl On

checkPrivateCache   1

checkPublicCache    1

maxCacheObjSize     10000000

maxStaleAge         200

qsCache             0

ignoreReqCacheCtrl  1

ignoreRespCacheCtrl 1

enableCache         1

expireInSeconds     3600

enablePrivateCache  1

privateExpireInSeconds 3600

And here is the basic htaccess I have in the root of the wiki directory, which is what you're instructed to have:



<IfModule LiteSpeed>

CacheLookup on

</ifModule>

I do have the extension set to enable the cache and to cache for logged-in users as well.

Anyone have experience with this extension and why it may be acting so oddly? Thanks!

AndreyPopov · Jan 28, 2024

Balerion said:

ike I answer on Slack - on OLS lscache store always in /priv folder

Balerion said:

may be try in server configuration

Code:

enableCache 0
expireInSeconds 3600
enablePrivateCache 0
privateExpireInSeconds 3600

make

Code:

enableCache 1
expireInSeconds 864020
enablePrivateCache 1
privateExpireInSeconds 3600

also check access rights (permissions) on lscache store folder.

Cold-Egg · Jan 29, 2024

Just curious, have you set LiteSpeed Public Cache Enabled to checked and click the Save Cache Setting button from the MediaWiki special pages?

Balerion · Jan 29, 2024

Cold-Egg said:

I did. I'm really quite stumped. I even went to Wikiapiary to verify that other wikis using the cache were having success -- found a number that weren't using it, but two that were with seemingly no issues.

I'm in the middle of upgrading the wiki to a later version to see if maybe there's something weird about 1.31 that other versions don't have. One of the sites using it successfully is on 1.32.

Cold-Egg · Jan 30, 2024

Please keep us updated.

Balerion · Feb 1, 2024

Cold-Egg said:

Alas, a sad update -- I really can't figure out why this isn't working. I upgraded to 1.35 of Mediawiki, and still no joy.

I found two other wikis out there that seem to be using LS Cache successfully, so I compared response headers. The only thing I could see as a real difference between us is that my php.ini had session.cache_limiter set to no cache, leading to a Pragma: No-cache header. I fixed that. Here's what LS Cache check shows now:

Here's one of the other wikis using the plugin, when I go to a page that doesn't exist, to see what the miss looks like:

And now the other site, again forcing a miss:

The only thing I can see remaining at the moment is that my Expires updates to be at the same time as when I examine the page, which is obviously some sort of error. I need to see why that happens. The first of the two sites seems to be setting some special cookie, but tha is probably unnecessary. I have some additional header I don't know anything about, but it doesn't seem to change. Both of the others have User-Agent as part of the Vary header, but I don't know if that's necessary for caching to work. The first of the other sites don't have the x-Request-ID header, but the second does...

If anyone has additional thoughts based on the above, let me know! Kind of at my wits end. I'm going to look at the expire header, see if I can do antyhing about it.

Balerion · Feb 3, 2024

A small advance, but I don't really know why. I reset everything and re-did the Cache settings and htaccess, and now when I try check.lscache.io, I actually will get hits. Which is great....

But when I check with an actual browser, no caching. What would be the difference between these two things? Does anyone know? Could this be PHP session or cookie related?

Just to make it easier, the site I'm working on is https://wiki-test.westeros.org, where we're working to hopefully eventually move https://awoiaf.westeros.org (NGINX+Varnish, not Litespeed).

AndreyPopov · Feb 3, 2024

Balerion said:

probably cookie
Vary: Accept-Encoding, Cookie
Vary: Accept-Encoding, Cookie,User-Agent

check.lscache.io not accept external cookies that's why use lscache without cookie vary

actual browser accept cookies and use lscache with cookie vary

Balerion · Feb 3, 2024

AndreyPopov said:

Interesting. Is there some way to tell the cache to ignore cookies, then? Because the other two sites that have working caches are working in the browser, not just check.lscache.io, and they have the same header. Here's one of the sites.

AndreyPopov · Feb 3, 2024

Balerion said:

this site on LiteSpeed server, not OLS (OpenLiteSpeed)

LiteSpeed Web Server (LSWS) server support br encoding for stored lscache (gzip also supported).
OLS support only gzip encoding for lscache.

LSWS can provide stored in br encoding lscache for all encoding requests: br, gzip, deflate, nocompress.

OLS cannot provide stored in gzip encoding lscache for only br encoding request. for only br encoding request OLS provide non-cached page.

Balerion · Feb 3, 2024

I did not realize that. But here is the other site, it doesn't show br encoding.

AndreyPopov · Feb 3, 2024

Balerion said:

check.lscache.io send only gzip encoding request and LSWS "on the fly" recompress br encoding stored page to gzip encoding and provide.

page stored at lscache in br encoding. only LSWS can this.

LiteCache · Feb 4, 2024

Balerion said:

You seem to have a misunderstanding of check.lscache.io. This test page only verifies that LScache works by checking for the presence of the x-litespeed-cache header, but nothing else and regardless of cache varies a cache plugin can provide. In the case of MediaWiki, and if you have the private cache option enabled in the MediaWiki cache plugin, the login status cookie is relevant to another cache vary or copy of the cache. However, check.lscache.io does not and cannot simulate real browser requests. This is important if you have the Private Cache and/or Mobile Device Cache option enabled, as the cache copy (content) depends on the login status and/or device used. This means that you must not use check.lscache.io if you want to test whether the cache varies work. Instead, just use the browser development console to check cache status!!!

The Vary Response Header has nothing to do with whether LScache works or not and has no impact on LScache. This header is set by MediaWiki and simply informs the browser that the content may be different depending on whether a cookie is set. This Vary header also informs the browser that MediaWiki serves different content depending on the user agent used to serve different content to mobile devices. The same applies to Accept-Encoding, but here too the Vary header has nothing to do with LScache.

In order to rule out a malfunction, temporarily deactivate the private cache function and, if set, also the cache for mobile devices. Also delete all cookies in your browser and purge the cache as a final step. Then check the x-litespeed-cache response header status in your browser. You should also check whether there is a proxy in front of your server, because I noticed that the cache-control header for browser caching has values that are not set by either the LiteSpeed cache plugin or MediaWiki.

AndreyPopov · Feb 4, 2024

@Balerion
may be, you need to disable in header request Vary: Accept-Encoding for OLS?

Balerion · Feb 4, 2024

LiteCache said:

I think it does two things, doesn't it? Checks to see if there is LS Cache support (presence of header), and then whether it's actually working (presence of 'hit' rather than 'miss'). Those two sites, I can check a page, get a miss, and then on re-load get a hit after it has cached it. Ditto with my own site, but only with Cache Check (or Curl, I guess), but not via browser, for the reasons you state.

I actually don't have private cache enabled at all, and my tests showing failures were using incognito mode, with login cookie.

My one thought is this: does the plugin look for _any_ cookie? Because the website has ads, it has a consent cookie and then cookies relevant to ad-serving, and we have Google Analytics which also places a cookie. If it just checks, "Have we set some cookie?", then I guess this may explain why I get misses on public cache.... But even after enabling private cache, shouldn't _then_ it be giving me a private cache? But that never seems to work.

I tried to look at the plugin to understand how it actually functions in terms of how it identifies the private cache vs public cache, but couldn't quite make heads or tails of it.

I added additional headers based on recommendations from Chrome's Lighthouse, for security and so on. I can strip them out again. I think the only proxy thing I had was this in htaccess, when setting up PHP-FPM:
<FilesMatch \.php$>
SetHandler proxy:fcgi://westeros-php81
</FilesMatch>

But removing that seems to have no impact, either.

To try and simplify as much as possible, I've switched to a skin that is adless and doesn't set any cookies, but it does still have GA on it. I guess I can disable that too and see what happens. I'll drop cookies hiding in my browser despite incognito mode, as well, just to be sure...

Huh, well, look at that. It works, and I've confirmed the private cache is also working. So... it seems that the problem is all the other cookies from consent, GA, ads are the issue, and somehow prevent it from giving cache hits, even if you arent' logged in.

Is there any way to tell it to ignore all cookie setting/cookies except the login cookie?

ETA: Bit further testing, even if I just leave Google Analytics, that cookie seems enough to never get a cache hit again, whether private or public. So I just need to figure out how to get the plugin to ignore any cookie but a login cookie, I think...

LiteCache · Feb 5, 2024

Balerion said:

No and as already said check.lscache.io only checks the presence of LiteSpeed cache header. check.lscache.io is not a cache tester, so the status of the cache header doesn't matter. That's why I have to emphasize it again. Never use check.lscache.io to verify if the cache is working. It just checks the header but nothing else!

If, as you say, the cache works for a request with curl or with check.lscache.io, but not for a browser request, then that suggests that you are trying to test the cache using the browser's private mode. Never do that! This is not a reliable method to test the cache. Especially not if you have activated the cache for logged in users.

Regardless, I repeatedly wonder what the problem is?! With every request from your site, the cache works perfectly and as expected. As I already wrote in the LiteSpeed Enterprise forum, I installed MediaWiki and the cache plugin for test purposes and everything worked without any problems in this test installation.

I can only emphasize that you follow my advice, as there is no reason to look for a cause of a malfunction, because there is neither a reason nor a cause.

Balerion · Feb 5, 2024

LiteCache said:

Does your Mediawiki have Google Analytics cookies being served from it? Mine does, and it does not seem to work when the site puts any cookies on besides the login cookie.

I'm no longer looking for a malfunction, I'm now wondering how to adjust the plugin or LS Cache rules to ignore those other cookies for caching purposes.

LiteCache · Feb 5, 2024

Balerion said:

The cache plugin ignores all cookies except for the login cookie because it has no corresponding settings/functions to take cookies into account. That is why GA does not influence the cache function.

But I noticed that you have changed the settings for the browser caching since your first post. In your first post you still had the value: s-maxage. s-maxage defines the cache behavior when a proxy is present and inevitably leads to misconduct from LScache. s-maxage is not a LiteSpeed header value.

Balerion · Feb 5, 2024

Right, I have reset things a lot, and I am glad I am getting hits on a vanilla Mediawiki... but I still don't know why it's not working when I have the other cookies in. I'm going to restore them...

Here is the actual test site we're working on, that has been presenting these problems.

LiteCache · Feb 5, 2024

https://wiki-test.westeros.org/index.php/Main_Page?test=11

LSCache Mediawiki Plugin

Member

Member

Administrator

Member

Administrator

Member

Member

Member

Member

Member

Member

Member

Active Member

Member

Member

Active Member

Member

Active Member

Member

Active Member