Fixing OpenLiteSpeed Caching for ActivityPub on WordPress

I have been using the #ActivityPub plugin for #WordPress for many years, I’ve also been using the #OpenLiteSpeed web server for probably just as long(or more). In all that time I wasn’t actually aware that my site had a major caching issue, mostly because I wasn’t really pushing my WordPress site as something to directly interact with on the #Fediverse. I was still manually posting to my #Mastodon account with a link to my website.

Some Backstory

Since last fall when the Twitter apocalypse started to happen, and the rush on new users to the Fediverse, I started using my WordPress site as more of a first stop participant on the Fediverse. I follow my website on Mastodon and boost my website posts. As I started doing this, and as others have also started to think about using the ActivityPub plugin on their own WordPress sites, I became aware of a major issue with the caching on my site where sometimes Fediverse users were getting straight HTML and sometimes my website visitors were getting #JSON.

After some conversation with others on Mastodon about other caching issues with ActivityPub & WordPress it was revealed that it came down to the Accept headers being received by requests to the caching services. The caching services could be things like #Cloudflare or web servers such as OpenLiteSpeed, or even WordPress caching plugins. In my case I use the OpenLiteSpeed web server caching and I started digging into how caching works in OpenLiteSpeed and how I could fix it for my WordPress site.

The Research, Debugging, and Testing

My research initially took me to some details in the OpenLiteSpeed documentation about the possibility of setting up difference caches for mobile versus desktop.

There was also some documentation related to creating different caches based on geographic locations.

The commercial LiteSpeed Enterprise documentation goes into much more detail about the use of Vary cache keys. And this further pointed me in the right direction. I went down the road of starting to write some Rewrite rules and testing them with PostMan & curl to check the responses. There were a couple of times that I thought I had things finally working, and even shared them in some various places. However, once again someone pointed out to me that my website was serving up JSON to website visitors. Back to more debugging. This time I used my Mastodon instance and the post/user search functionality to send the requests and I turned on high levels of logging in OpenLiteSpeed and finally found that the Accept headers being sent from Mastodon were a bit more broad than my Rewrite rules were accounting for. I didn’t get the full headers I found saved here and they have now been cleared so I can’t provide the actual findings. Things seem to be working now with the fix outlined below.

OpenLiteSpeed Fix Using a Rewrite Rule

The fix that ultimately worked in my testing was a pretty simple Rewrite rule in my site’s root .htaccess file.

#BEGIN ActivityPub Cache Handling
<IfModule LiteSpeed>
RewriteEngine On
CacheLookup On
RewriteCond %{HTTP_ACCEPT} application\/((activity|ld)\+json|json|ld\+json.*profile.*activitystreams") [NC]
RewriteRule .* – [E=Cache-Control:vary=%{ENV:LSCACHE_VARY_VALUE}+activitypub]
</IfModule>
#END ActivityPub Cache Handling

Update: The RewriteCond was case-sensitive and there were cases reported of some remote agents sending some requests with upper case values. [NC] was added to the RewriteCond to mitigate this issue. Thanks go to the Mastodon user that shared this with me here: