Closed jeherve closed 1 year ago
Related changes In WP Super Cache:
This was also brought up here: https://github.com/pfefferle/wordpress-activitypub/issues/301
I am one of the paying customers at wordpress.com (2 business tier and 2 ecom tier at this point) and I would like to add myself in the list of people who need this resolved to have activity-pub features on my website. Is there any way we can ask for this to be prioritised. any indicator we can give that this is a problem for people hosted at wordpress.com
This should be fixed in bf3aed9.
@vnsavage https://github.com/Automattic/batcache/commit/bf3aed995ecd6d8544d4f776ac719bbb0addaac2 seem to fix this issue only if there is one single Accept header (false === strpos( $_SERVER['HTTP_ACCEPT'], ',' )
), Mastodon and Misskey for example might send a list of different Accept headers.
There is also a very special, but supported Accept header, that will not be caught by the change: application/ld+json; profile="https://www.w3.org/ns/activitystreams"
https://www.w3.org/TR/activitypub/#retrieving-objects
I have a Rewrite rule that I created that properly accounts for the variation of accept headers documented here: https://www.timnolte.com/2023/04/09/fixing-openlitespeed-caching-for-activitypub-on-wordpress/
@pfefferle - yes, that's on purpose. I prefer this to be as tight as possible to try and create as few cache variations as possible and also avoid false positives. But since some of these clients are somewhat large ( e.g. Mastodon ), I added some functionality to support multiple headers in c925578.
Just wanted to say thanks to all of you folks. I can confirm this fix is helping wordpress-activitypub plugin on wp.com hosted sites also : https://github.com/Automattic/wordpress-activitypub/issues/301#issuecomment-1541877374
Some plugins, like the ActivityPub plugin, allow getting a JSON object representing your post when querying a post URL with an
application/json
header.This proves problematic when using Batcache, since those requests end up being cached (a potentially good thing), but served back to regular site visitors.
Here is an instance of this happening: https://fedi.jeremy.hu/@jeremy/statuses/01GVFG2QMBJTFH4VBJT2VZQ8NZ
It would be nice if such requests were at least not cached, or maybe cached separately so they could be served back later on.