WP Supercache seems to ignore non-default “Accept” header

  • Resolved alecmuffett

    (@alecmuffett)


    1 year, 4 months ago

    I am running WordPress 6.3.2 with Jetpack, Akismet, WP Supercache, AddToAny, and the ActivityPub suite, under NGINX

    If I disable Supercache, my ActivityPub plugin works fine and my posts are visible to Mastodon, etc.

    If I enable Supercache, they stop working, because as described at:

    https://github.com/Automattic/wordpress-activitypub/discussions/446#discussioncomment-7332341

    and also:

    https://github.com/Automattic/wordpress-activitypub/discussions/446#discussioncomment-7332671

    …when Supercache is enabled the page at https://alecmuffett.com/article/author/alecm stops honouring the Accept: application/activity+json header, and returns cached HTML irrespective of the request for JSON.

    I’ve tried it with Supercache in Simple mode, and with it in Expert mode although with the latter I have, of course, had to manually tune NGINX to tune the accelerated page fetches; this has been complicated by the apparent behaviour that even in Expert mode, Supercache seems to fall back to PHP/Simple caching in the event that the request was not served directly out of NGINX? If so, it seems like even a move to “Expert” caching and making NGINX ignore the static-cached page for that URL when Accept is not text/html, is doomed as a potential solution.

    (update: I came to this conclusion because I switched on NGINX without modifying the NGINX config to serve cached pages direct from the filesystem… and I was astonished to find that I was still serving cached content. I’ve not tried debugging this before, but I presume that this means “when expert mode is enabled, simple/php-caching is still enabled as a fallback?” ; if so this makes it very hard to determine which mechanism is serving the cached content without (as I did) enabling NGINX low-level debugging.)

    At the moment I have got Supercache switched off because it’s important to me that my ActivityPub work. I am happy to “Restore defaults” and debug that way if anyone wants.

    • This topic was modified 1 year, 4 months ago by alecmuffett.

    The page I need help with: [log in to see the link]

Viewing 7 replies - 1 through 7 (of 7 total)
  • Thread Starter alecmuffett

    (@alecmuffett)

    To recap the two Github comments that I reference above:

    1/ … I am having HTML returned by

    curl -v -sS -H ‘Accept: application/activity+json’ https://alecmuffett.com/article/author/alecm

    …too, and for me I have identified the problem as WP-SuperCache (I nuked the cache and did the above request, and it returned JSON) so I am trying to work out a way to get SuperCache to ignore “application/activity+json” requests.

    2/

    okay, so I did a var dump to check FPM:

    …and I can guarantee the result includes:

    ‘HTTP_ACCEPT’ => ‘application/activity+json’,

    …so I can be certain that the Accept header is making it to the PHP stack; it seems like WP-SuperCache is ignoring it and treating “all the world’s an HTML object?”

    For the moment I have disabled supercache and run my test suite, and with WPSC off everything now appears to be working OK (although it’s not a fully comprehensive test)

    There are various pages online about enabling certain vars in certain code to disable WPSC; that may or may not be relevant. Another approach might be to adopt “Advanced” rather than “Simple” caching and use NGINX to avoid ever returning cached content for other than the appropriate content accept-types.

    But it would be nice to make WPSC a little smarter, if indeed that is where the problem rests.

    Thread Starter alecmuffett

    (@alecmuffett)

    Dump of the last set of settings that I was using, because someone always asks for settings:

    https://alecmuffett.com/alecm/tmp/wpsc.png

    Thanks. I’ve replicated the problem. If the author page isn’t cached, then it returns JSON, but a cached page will be returned if it’s available. ??

    Issue created to track this: https://github.com/Automattic/jetpack/issues/33968

    Thread Starter alecmuffett

    (@alecmuffett)

    Awesome, thank you. Inspired by this confirmation I am testing a workaround of adding /author/ to the Rejected URL strings, and I’ll check out the behaviour now and over the next 24h to check.

    While I am here: is my theory correct please that Expert mode basically falls-back to PHP-caching if a cached page is available and servicing the request has not been usurped by {Apache,NGINX}?

    My reason for asking is to find out the best way to be certain that pages are being served by the webserver directly from the filesystem, without having to call into PHP; and that such a fallback apparently makes doing-so rather hard (false-positives) unless PHP sets a header that’s distinct from the raw webserver, perhaps?

    I found the bug. In wpsc_get_accept_header in wp-cache-phase2.php, there’s a strpos() check:

    if ( strpos( $accept, $header ) ) {
    $accept = 'application/json';
}

    Change that strpos to this and it will fix it:

    if ( strpos( $accept, $header ) !== false ) {

    I’ll make a PR shortly and get it merged.

    While I am here: is my theory correct please that Expert mode basically falls-back to PHP-caching if a cached page is available and servicing the request has not been usurped by {Apache,NGINX}?

    Yeah. If expert mode fails, then it falls back to PHP to serve the cached file. It’s almost as fast as the database isn’t touched.

Viewing 7 replies - 1 through 7 (of 7 total)
  • The topic ‘WP Supercache seems to ignore non-default “Accept” header’ is closed to new replies.