abb78790 on "[Plugin: W3 Total Cache] 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.