X-Pj-Cache-Status: miss

What are some of the other headers you see in response to your cURL request? One thing that could cause this is a cookie header, such as PHPSESSID, etc.

Thanks for your reply.
I re-installed the plugin and now I don’t see the header “X-Pj-Cache-Status” anymore.
Anyway, here is the whole output of my current header:

HTTP/1.1 200 OK
Server: cloudflare-nginx
Date: Mon, 28 Mar 2016 19:34:52 GMT
Content-Type: text/html; charset=UTF-8
Connection: keep-alive
Set-Cookie: __cfduid=da335aa9644c62916d59fde91d3a5eeac1459193692; expires=Tue, 28-Mar-17 19:34:52 GMT; path=/; domain=.*************.net; HttpOnly
Link: <https://*************.net/wp-json/>; rel="https://api.w.org/"
Set-Cookie: jreject=1; path=/
Vary: Accept-Encoding
X-Frame-Options: SAMEORIGIN
X-XSS-Protection: 1; mode=block
X-Content-Type-Options: nosniff
Age: 81
X-Cache: cached
CF-RAY: 28ad85a4e5843c83-CDG

Here is my setup:
Varnish
Apache2
PHP5-FPM with zendopcache enabled
MariaDB
Redis-Server

Hope this will help.

Thanks for the info! It seems like the re-install didn’t really work since you’re now not seeing the header at all. Please try to reinstall it again following the instructions.

Also, if you’re still seeing a cache miss, try getting rid of the plugin that issues the “jreject=1” cookie. It’s probably causing the caching plugin to not cache the request because of that cookie.

Hope that helps!

Same here. I always get a miss-header back. My redis-server is not on localhost – so I’ve changed $redis_host to point to the external server. Anything else I need to change? At least the plug is active and talks to the redis-server. If I do a ‘ab -n100 -c10 url/’ (hit the server with an apache benchmark) I see a lot of keyspace_misses (redis-cli) but no hits at all.

Got it to work finally! Was a plug that did not behave (WP Limit Login Attempts). This thing is incredible fast. Like 10 times faster than disk based caches.

Glad you got it to work @kochtopf. For password bruteforce protection we recommend running fail2ban on the server instead of a WordPress plugin.

That sucks.
After re-installing the plugin, I can’t make it work again.
However when I installed it for the first time, it worked, I mean I could see “X-Pj-Cache-Status” with cURL.
I also have Varnish, and Varnish can also make full page caching and it also caches static ressources. Do you think this plugin is still useful as Varnish can do the same ?

If you’re using Varnish with a high-enough TTL then you don’t really need this plugin, since everything you can do in this plugin config can probably be done in the Varnish configuration as well.

I also find WP Limit Login Attempts is not compatible with Redis Page Cache. After delete the WP Limit Login Attempts plugin, the cache work like a charm.

We’ll have to test this and make sure. Can you provide more information, please? How does the incompatibility manifest itself? What is the expected behavior? What happens instead?

Thanks!

Hi, Gennady Kovshenin

with WP Limit Login Attempts enabled, whenever vista a page, I could always see the unexpected header:

X-Pj-Cache-Status: miss and the X-Pj-Cache-Key

I guess the Set-Cookie section obstruct the Redis Page Cache. This cookie may generated by WP Limit Login Attempts. When removed, I could not see this cookie any more.

< Server: nginx
< Date: Wed, 24 Aug 2016 14:11:18 GMT
< Content-Type: text/html; charset=UTF-8
< Transfer-Encoding: chunked
< Connection: keep-alive
< Vary: Accept-Encoding
< X-Pj-Cache-Status: miss
< X-Pj-Cache-Key: 5950a8bd06ebc09b5e754639d00c1054
< Set-Cookie: PHPSESSID=2lmih9j1s724uno3fp4p649f37; path=/
< Expires: Thu, 19 Nov 1981 08:52:00 GMT
< Cache-Control: no-store, no-cache, must-revalidate
< Pragma: no-cache
< Strict-Transport-Security: max-age=15768000; includeSubDomains; preload
< X-Frame-Options: DENY
< X-Content-Type-Options: nosniff
< X-XSS-Protection: 1; mode=block

Another test:

< HTTP/1.1 200 OK
* Server nginx is not blacklisted
< Server: nginx
< Date: Wed, 24 Aug 2016 14:08:27 GMT
< Content-Type: text/html; charset=UTF-8
< Transfer-Encoding: chunked
< Connection: keep-alive
< Vary: Accept-Encoding
< X-Pj-Cache-Status: miss
< X-Pj-Cache-Key: 5950a8bd06ebc09b5e754639d00c1054
< Set-Cookie: PHPSESSID=6397vt4g9ct31k32h645p52m43; path=/
< Expires: Thu, 19 Nov 1981 08:52:00 GMT
< Cache-Control: no-store, no-cache, must-revalidate
< Pragma: no-cache
< Strict-Transport-Security: max-age=15768000; includeSubDomains; preload
< X-Frame-Options: DENY
< X-Content-Type-Options: nosniff
< X-XSS-Protection: 1; mode=block

Once the plugin was removed:

< Server: nginx
< Date: Wed, 24 Aug 2016 14:14:33 GMT
< Content-Type: text/html; charset=UTF-8
< Transfer-Encoding: chunked
< Connection: keep-alive
< Vary: Accept-Encoding
< X-Pj-Cache-Key: 5950a8bd06ebc09b5e754639d00c1054
< X-Pj-Cache-Time: 1472048065
< X-Pj-Cache-Flags: url:268246bb6ef4c6089710152720b971ae
< X-Pj-Cache-Status: hit
< X-Pj-Cache-Expires: 21592
< Strict-Transport-Security: max-age=15768000; includeSubDomains; preload
< X-Frame-Options: DENY
< X-Content-Type-Options: nosniff
< X-XSS-Protection: 1; mode=block

Are you using the latest version of LLA? A quick scan of the code doesn’t reveal any calls to session_start, so not sure why it would be even loaded in the frontend.

I check the source code of it and find session related functions in wp-limit-login-attempts.php:

function wp_limit_login_init(){

function is_session_started(){
if ( php_sapi_name() !== ‘cli’ ) {
if ( version_compare(phpversion(), ‘5.4.0’, ‘>=’) ) {
return session_status() === PHP_SESSION_ACTIVE ? TRUE : FALSE;
} else {
return session_id() === ” ? FALSE : TRUE;
}
}
return FALSE;
}

if (is_session_started() === FALSE ) session_start();

add_action(‘login_head’, ‘wp_limit_login_head’);
add_action(‘wp_login_failed’, ‘wp_limit_login_failed’);
add_action(‘login_errors’,’wp_limit_login_errors’);
add_filter( ‘authenticate’, ‘wp_limit_login_auth_signon’, 30, 3 );
add_action( ‘admin_init’, ‘wp_limit_login_admin_init’ );

We are using Softlayer.com server for our website :

https://www.purelocal.com.au

Because SoftLayer charge us about $1 per GB in bandwidth we put our site on CloudFlare to reduce costs and to make it faster….

Now we find out that most servers include response codes to block malicious hacks and these response headers block cloudflare from caching…

Feeling completely ripped off by Cloudflare now for taking our payment without checking our domain was even compatible in the first place. Cloudflare ask us to remove the response headers blocking their caching and our server says they won’t remove it because it’s crucial for security.

I’ve tried to override the cache headers in .htaccess to no avail.

Can someone please explain why Cloudflare are doing this paying customers?

Rip.Off.