W3TC disk_enhanced Page caching gzip debugging
-
First, thanks Frank for such a great and comprehensive plugin.
I am using W3TC 0.9.2.11 with Woocommerce and some other standard plugins hosted on nginx + php-fpm.
I’ve boiled the problem down to the disk_enhanced page caching (all other w3tc caching steps are turned off to isolate the issue). Concisely:
++ the caching module properly produces the _index.html and _index_ssl.html files on the first request to a given url and then nginx is able to subsequently serve these using nginx rules (thereby bypassing wp+php altogether). This behavior can be reproduced and tested using curl. These files are properly stored in the
cache/page_enhanced/<site>/<uri>/
directories.— the problem is when “Accept-encoding: gzip” is included in the request (as all modern browsers add). In this case, the first request loads fine (and sends a gzipped response), but then subsequent requests fail. The _gzip version of the cache file is not produced in that same directory. The failure manifests itself in a few ways. At some point, there were 500 response codes. But I disabled everything else, and now the response can be consistently reproduced as a 200-code with the following headers, and no actual body:
HTTP/1.1 200 OK Server: nginx Date: Wed, 19 Jun 2013 22:50:49 GMT Content-Type: text/html Transfer-Encoding: chunked Connection: keep-alive X-Powered-By: PHP/5.3.25 Vary: Content-Encoding: gzip
I am happy to do the legwork to track this down, but I just need a few hints on how to start debugging. Unlike rails, I don’t know how to interactively debug php-fpm, or this plugin. Blackbox debugging would be great; i can’t even seem to get the php log files to track down the code paths that are followed in the gzip request.
Help appreciated.
- The topic ‘W3TC disk_enhanced Page caching gzip debugging’ is closed to new replies.