Falcon Cache and InfiniteWP

I’ve contacted the author of InfiniteWP and he says he is reaching out to the author of WordFence, to discuss this.

– Scott

Hi Scott,

Strange. Can you post your .htaccess file here and exclude any sensitive info. Looks like your gzip files are being served up raw rather than the browser interpreting them as compressed content. That points to a web server config issue. I don’t think we’ve had any other reports from this but I’ll let Tim weigh in.

Any other web server config info you think might help would be useful.

Thanks.

Mark.

This is definitely not a GZIP related thing. What is being output is a base64 encoded serialization of an array output by IWP.

iwp-client/init.php line 274: exit(“<IWPHEADER>” . base64_encode(serialize($return)).”<ENDIWPHEADER>”);

If you search google for “IWPHEADER” you will see the bottom of the first page and most of page two are other sites borked by WordFence caching InfiniteWP’s output.

Randomly picking one of the google results I base64 decoded and unserialized it. You can see the reults here: https://pastebin.com/Vece2Kv6

The real issue is that this IWP output shouldn’t be cached (or maybe it shouldn’t be output in this way?). It appears to be IWP communicating back to its dashboard installation the state of the site.

Bob

Hi Mark. Here is the htaccess file. It is a standard WordPress .htaccess file, generated when Permalinks are enabled, plus WordFence Falcon caching enabled. Nothing else added, to the best of my knowledge.

https://dl.dropboxusercontent.com/u/58440730/wf-htaccess.txt

FYI, I am the owner of the server (and web hosting company) so if this points to a “web server config issue” the buck stops here. We run a very standard cPanel / CloudLinux LAMP setup here, but I’m willing to look at anything you want me to look at.

– Scott

Guys I’m a bit confused by what’s going on here.

On our side, we simply use standard PHP output buffering including ob_start() and ob_get_contents() to just grab the PHP output and generate our cache files. That is how all other PHP based caching plugins work.

So we’re just grabbing whatever the application is giving us for a particular page and storing in in a file which is associated with the URL that was accessed.

Can you give me a few theories about why InfiniteWP is triggering this weird behaviour? Or where the conflict might be? Is InfiniteWP sending the HTTP response or page content using some non-standard mechanism? Or is it using output buffering itself which conflicts with our buffering? Or is InfiniteWP doing caching too?

I’ve confirmed that this is the only report we’ve seen of this issue.

Thanks.

That .htaccess looks like it’s our standard Falcon caching code with the WP code – so normal.

I’m seeing liberal use of the ob_ functions in the InfiniteWP code here:

https://plugins.svn.www.ads-software.com/iwp-client/trunk/init.php

So I suspect that’s causing an issue with our buffering/caching, so recommend the customer disables Falcon (and basic caching) if they want to use InfiniteWP to immediately resolve the conflict. This conflict will probably arise with any other caching plugin for WP.

Note, I haven’t fully examined the InfiniteWP code – just searched it for ob_ related functions and this is my suspicion.

Mark.

Hi Mark. I had also opened a ticket with InfiniteWP (Ticket #35103). David at InfinteWP said he has emailed “them” (assuming some email @ wordfence.com) yesterday, so you might look for that. I’ve also asked him to chime in here on this thread.

Thank you very much for your help. We are BIG believers in WordFence and also in the Falcon Engine, and I sure hate the thought of having to choose between WF caching and IWP. I’m hoping the “conflict” can be resolved.

– Scott

Sneader – We will definitely get this sorted ASAP.

Mark – We have been using ob_start for a long time now. We call the index WP URL to run an execute and it gives us a response. We are also getting a support ticket on this issue for the first time. It looks like the response from our IWP plugin is getting cached.

I am willing to get this fixed ASAP.

Thanks
David.

Mark – researching a bit we are sending a RAW POST call and the plugin is producing that output. Is it a good idea to cache the RAW POST calls? I am just thinking out loud ??

FYI, I had four customers come to me today, saying their sites were down… all had white pages with the one line of Base64 at the top.

I’ve seen this problem from time to time before, but I could go a month or two between seeing it, so it is odd that it’s happening so much more frequently now.

– Scott

I just manually went through all the sites I manage in InfiniteWP, and found about 30% of them were “down” with the Base64 coded line.

Mark, are you still with us on this? Sure would like your help!

– Scott

Hi Scott,

I’m one of the Wordfence developers and have been looking into the issue your having. I’ve haven’t been able to replicate the exact behaviour, but I have found scenarios where I can get the IWP client response to be cached. If the request uses the GET method with a message body, the InfiniteWP client plugin will still use and process it since it checks php://input which is available for any HTTP method. Wordfence does check that the request method is GET before caching (see line 88: https://plugins.svn.www.ads-software.com/wordfence/tags/6.0.11/lib/wfCache.php). I looked at the IWP admin code, and their doCall method which from what I can see is the only way they call the IWP client should only send requests using POST. It’s possible one of their add-ons is making that call, but I don’t have that code available to troubleshoot it.

Since I don’t have a direct solution to your problem, I can give you a workaround to use that hopefully will stop bringing down your sites in the meantime. The IWP admin offers a way to specify the /wp-admin/ as the URL to connect to when it talks to the IWP client plugin (Edit Site Details > Advanced > Connect Using). The Wordfence cache does not cache anything in /wp-admin/ so hopefully that works as an alternative.

– Matt

Matt all the calls made to WordPress sites uses doCall. So we only do HTTP RAW POST calls. We never do any GET calls.

https://pastebin.com/Vece2Kv6 – this is a plugin data fetching call which happens in the free version.

I think HTTP RAW POST calls are misunderstood by your cache may be?

Thanks
David.

@sneader: Did wfmatt’s solution above help? If it happens again on any of your sites, can you check the date and time on the cache file, and find the request with the same date/time (or slightly before it) in your access_log file?