skepticwebguy

Thank you very much for your help. Really great!

I decided to see if there was an update to the 5G Firewall and there was. So, I applied inserted those htaccess rules instead and now Disk:Enhanced Page Caching works!

https://perishablepress.com/5g-blacklist-2013/

The way some of those rules were written changed in the new 5G Firewall update.

Thank you. I have the following rules in my htaccess file and the last one matches the criteria you mentioned:

# 5G BLACKLIST/FIREWALL
# @ https://perishablepress.com/5g-blacklist-2012/
<ifModule mod_rewrite.c>
RewriteEngine On
RewriteBase /
RewriteCond %{QUERY_STRING} (environ|localhost|mosconfig|scanner) [NC,OR]
RewriteCond %{QUERY_STRING} (menu|mod|path|tag)\=\.?/? [NC,OR]
RewriteCond %{QUERY_STRING} boot\.ini [NC,OR]
RewriteCond %{QUERY_STRING} echo.*kae [NC,OR]
RewriteCond %{QUERY_STRING} etc/passwd [NC,OR]
RewriteCond %{QUERY_STRING} \=\\%27$ [NC,OR]
RewriteCond %{QUERY_STRING} \=\\\’$ [NC,OR]
RewriteCond %{QUERY_STRING} \.\./ [NC,OR]
RewriteCond %{QUERY_STRING} \? [NC,OR]
RewriteCond %{QUERY_STRING} \: [NC,OR]
RewriteCond %{QUERY_STRING} \[ [NC,OR]
RewriteCond %{QUERY_STRING} \] [NC]
RewriteRule .* – [F]
</ifModule>

Thank you for clarifying. I turned Disk:Enhanced cache on again temporarily, recreate the 403 Forbidden error on a post, moved the page-cached _index.html to a folder outside of the cache folder in the site’s root in a test folder and tried to access it directly by browsing to: https://www.domain.com/test/_index.html

I was able to see the page just fine. Here are the response headers from redbot:

HTTP/1.1 200 OK
Server: cloudflare-nginx
Date: Sat, 28 Sep 2013 07:11:10 GMT
Content-Type: text/html
Transfer-Encoding: chunked
Connection: keep-alive
Set-Cookie: __cfduid=d1a0c05e9e97de54f3788bcbe8cdcc8461380352265300;
expires=Mon, 23-Dec-2019 23:50:00 GMT; path=/;
domain=.domain.com
Last-Modified: Sat, 28 Sep 2013 07:10:22 GMT
X-Powered-By: PleskLin
Vary: Accept-Encoding,User-Agent
Cf-Railgun: 5d606e98fa 0000 normal 33ca
CF-RAY: b4e9e1a226c03d6
Content-Encoding: gzip

I did exactly what you said. When I saw the 403 error on a post, I dug down into the chace hierarchy to find the cache _index.html_gzip file. I then moved that file to the root folder of the website and tried to browse directly to it. When I did that, the browser didn’t parse it as HTML. The browser spit out a giant page of nonsense like this:

?í?érI2.??d??…?S$o ?Y?’(‰jQò?V?í[#d€?¨\?ú”ùy?k6c66?2?r?düs?èL€à?$?fo @f?ê?{???t????u??ù(TˉT??(=Xen{wwWT¨??^¨￡áAíD?&?j′x???Y?…?eì??3à?…?

Then, when I ran that same URL through redbot, I got this:

HTTP/1.1 200 OK
Server: cloudflare-nginx
Date: Fri, 27 Sep 2013 05:15:37 GMT
Content-Type: text/html
Transfer-Encoding: chunked
Connection: keep-alive
Set-Cookie: __cfduid=d4a35b61c93b5fd92037a2fd576560e0a1380258937206;
expires=Mon, 23-Dec-2019 23:50:00 GMT; path=/;
domain=.domain.com
Last-Modified: Fri, 27 Sep 2013 05:13:22 GMT
X-Powered-By: PleskLin
Cf-Railgun: f31db86ce8 0000 normal 33ca
CF-RAY: b45b79584f403d6
Content-Encoding: gzip

I am using W3TC 0.9.3 which is the latest version.

I can confirm the naming scheme you mentioned. I noticed both _index.html and _index.html_gzip, and their old counterparts at various times.

I took one of the _index.html_gzip files and moved it into a different folder outside of the cache folder and tried to view it at the URL directly, like:

https://www.domain.com/_index.html_gzip

When I do that, I see lots gook, like (here’s just a tiny snippet):

?í?érI2.??d??…?S$o ?Y?’(‰jQò?V?í[#d€?¨\?ú”ùy?k6c66?2?r?düs?èL€à?$?fo @f?ê?{???t????u??ù(TˉT??(=Xen{wwWT¨??^¨￡áAíD?&?j′x???Y?…?eì??3à?…?

If I view that same _index.html_gzip in BBEDIT, I see a proper html file that previews as the proper page I expect to see in a browser.

When I run that URL through redbot, I get this:

HTTP/1.1 200 OK
Server: cloudflare-nginx
Date: Fri, 27 Sep 2013 05:15:37 GMT
Content-Type: text/html
Transfer-Encoding: chunked
Connection: keep-alive
Set-Cookie: __cfduid=d4a35b61c93b5fd92037a2fd576560e0a1380258937206;
expires=Mon, 23-Dec-2019 23:50:00 GMT; path=/;
domain=.domain.com
Last-Modified: Fri, 27 Sep 2013 05:13:22 GMT
X-Powered-By: PleskLin
Cf-Railgun: f31db86ce8 0000 normal 33ca
CF-RAY: b45b79584f403d6
Content-Encoding: gzip

General
The server’s clock is correct.
Content Negotiation
This response is negotiated, but doesn’t have an appropriate Vary header.
Content negotiation for gzip compression is supported, saving 0%.
Caching
The resource last changed 2 min 15 sec ago.
This response allows all caches to store it.
This response allows a cache to assign its own freshness lifetime.
Validation
If-Modified-Since conditional requests are supported.

– – –

After I recreated the 403 Forbidden error on a post, I used redbot.org to view the headers for the Forbidden post (https://www.domain.com/yyyy/mm/dd/post-title/) and here are the response headers from redbot:

HTTP/1.1 403 Forbidden
Server: cloudflare-nginx
Date: Fri, 27 Sep 2013 05:21:47 GMT
Content-Type: text/html; charset=iso-8859-1
Transfer-Encoding: chunked
Connection: keep-alive
Set-Cookie: __cfduid=d8af9ec465954dcb00ee9c1cbe29bdf881380259307693;
expires=Mon, 23-Dec-2019 23:50:00 GMT; path=/;
domain=.domain.com
Vary: Accept-Encoding
Cf-Railgun: a61c08871d 1.09 0.128803 0030 33ca
CF-RAY: b45c0a11c8903d6
Content-Encoding: gzip

General
The server has forbidden this request.
The server’s clock is correct.
Content Negotiation
Content negotiation for gzip compression is supported, saving 47%.
Caching
This response allows all caches to store it.
This response can only be served by a cache under exceptional circumstances.

I can download files with .gz extension no problem. Let me know more specific.

The files that gets created when a page is cached using Disk:Enhanced are:

https://domain.com/wp-content/cache/page_enhanced/www.domain.com/yyyy/mm/dd/post-title-hypenated/_index.html_gzip.old

https://domain.com/wp-content/cache/page_enhanced/www.domain.com/yyyy/mm/dd/post-title-hypenated/_index.html.old

If I tried to view this post twice: https://domain.com/wp-content/cache/page_enhanced/www.domain.com/yyyy/mm/dd/post-title-hypenated/

I’d get a 403 error that says this:

“You don’t have permission to access /wp-content/cache/page_enhanced/domain.com///_index.html on this server.”

I have no idea what the three forward slashes are doing there, but that’s what it say.

If I try to access this file directly: https://domain.com/wp-content/cache/page_enhanced/www.domain.com/yyyy/mm/dd/post-title-hypenated/_index.html_gzip.old

I get a bunch of gook:

??}?rG????H?sE??}!
R?.?Y??劲e?????J%?Z?nG???<?D??~?>??dΒYU?KIV_?{?TV.’?眼????^???’?+^?p?????h?^??Z_=?=y??{?ivZ?G?j???Om?$?~??X,??^3?f?W/[?M??/??M;?k??wi????òw;?ш?a?}W??ú??MxUI{|????I\5>9Sa?X7? q’?o??@???V]????tm?” ?????x*?3??^??/` ?>?gLG?$?\??Yp?\Wn??re?ml?e0P????#Q???0???/??n?>h?B?(L?? ???@?/?????7?J6?????

I am getting 403 Forbidden errors saying I don’t have permission to read the gzip version of the index pages that W3TC creates as cached versions of posts. So, I can read a post once, then the enhanced page cache is created, then I refresh, then I get the 403 Forbidden error for that page. Permission on that gzip index file is 644, as it should be, as far as I can gather from reading other posts on this issue.

Would I get the response headers using https://www.whatsmyip.org/http-response-headers/ when the error is occurring?

My (dv)4.0 CPU load average is often higher than 400%. The apparent cause is a process run by a domain user (on a domain where I am running a WordPress blog). The domain user calls on a process that calls on the domain’s php.ini file, which open up a crap load of lib64 files for every process.

My server memory and storage are not affected. It’s just CPU load.

Any suggestions?

Esmi,

Thanks for that. That’s likely it. Will give the patches a try and see how it goes.

Cheers!

I have been having the exact same problem for the past 4 weeks.

It only strips the inline style tag from the first div tag and not the rest of them in the post. Interestingly, a mysterious post revision appears dated with the same hour and minute as the last revision I made, yet the mystery revision says it’s “by ” (and no name is listed after the word by). By whom? And at the exact same moment I scheduled my post?

When I was done editing the post yesterday and scheduled it, I took a screenshot of the list of post revisions I had made. The mystery revision (by no one) was not there yesterday when I took the screenshot! It’s very bizarre.

Problem solved. I narrowed down the problem to something within my functions.php file in my theme. After some trial and error, I was able to narrow the problem down to having several hard returns after the closing ?> tag in my functions.php file. Removing those few hard returns solved the problem.

Now, I can see the comments on my Edit Post screen, as expected.

Do you have any idea what code in the theme files is responsible for displaying Comments in Edit Post mode?

That solves the problem. I’ll explore my custom theme and see what’s wrong. Do you have any idea what code in the theme files is responsible for displaying Comments in Edit Post mode?