Error 403 Forbidden using Disk:Enhanced Page Cache

Posting your site’s response headers would help to see, if there are any issues.

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

Yes, except for 444 (no response), response header is displayed for every request.

Posting 200 response header, may help. Posting 403 response header doesn’t help, though. 403 forbidden request, as the name suggests, is due to permissions in the server.

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.

Some hosts may have restriction on ‘.gz’ files. Try installing Google XML Sitemap generator plugin that generates sitemap.xml.gz file. Try accessing it (sitemap.xml.gz). If it shows 403 too, then it is a global restriction on / by the host.

Shorter solution – Copy the gzip file from the cache directory of W3TC and put it somewhere else, probably at the root directory of your site. Then try accessing it and see if you still get 403.

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?????

When using disk:enhanced mode for page caching, the created file would have the following name scheme…

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

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

Once the cache is cleared, the name would have a prefix “.old”. It happens only when the page is not revisited. If a particular page is visited again, then the “.old” gets removed.

I get a bunch of gook

Please use a site that gets only the response header, such as redbot.org. It helps in other ways too. For example, your local browser may have a cache and may interfere with some test conditions.

I’d get a 403 error that says this:

Please copy that file to another directory and see, if you can access it.

Btw, are you using the latest version of W3 Total Cache plugin?

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 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:

If you remember, the 403 occurs only on normal file. So, when you see 403, please copy the cached version of that particular request to another directory (probably to the root) and see, if you still get 403.

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 think I wasn’t clear.

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

Please find the cached _index.html file and copy it to another folder, probably the root of WP. That’s what shows 403 error. We don’t have to dig 200 responses.

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

It probably means there’s a .htaccess rule that forbids access to the same file from the cache directory. Please check for any htaccess file with the rule that may have [F] in it or in any sub directory of the root to WP. Here F means forbidden.

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>