Sovereign on "[Plugin: W3 Total Cache] Problems with decompressing gzip"

Problem

The first time a page is loaded on our website, we receive the following error in Safari, Firefox, and Chrome:

[Safari]

Safari can't open the page. The error is: "cannot decode raw data" (NSURLErrorDomain:-1015).

[Firefox]

The page you are trying to view cannot be shown because it uses an invalid or unsupported form of compression.

[Chrome]

The webpage might be temporarily down or it may have moved permanently to a new web address. Error code: ERR_CONTENT_DECODING_FAILED.

All subsequent refreshes load the page fine.

Enabled Features

We have the following features enabled in W3 Total Cache:

• Page Cache (Disk: Basic)
• Database Cache (Method: Disk)
• Browser Cache (w/ Gzip)

Platform

Some additional information about WordPress and the environment:

• WordPress MU 3.5.2 (Subdomain version)
• W3 Total Cache 0.9.3
• Apache 2.2.15
• PHP 5.4.17

Additional Information

WordPress is installed in a subdirectory, but served from the root.

All W3 Total Cache installation requirements have been manually fulfilled, although it's not recognizing that the htaccess rule:

# BEGIN W3TC Browser Cache
<IfModule mod_deflate.c>
    <IfModule mod_headers.c>
        Header append Vary User-Agent env=!dont-vary
    </IfModule>
        AddOutputFilterByType DEFLATE text/css text/x-component application/x-javascript application/javascript text/javascript text/x-js text/html text/richtext image/svg+xml text/plain text/xsd text/xsl text/xml image/x-icon application/json
    <IfModule mod_mime.c>
        # DEFLATE by extension
        AddOutputFilter DEFLATE js css htm html xml
    </IfModule>
</IfModule>
# END W3TC Browser Cache

is in place, since it's looking for the htaccess file in the subdirectory as apposed to the root.

Lastly, w3tc-wp-loader.php points to wp-load.php in the root (where it doesn't exist) as apposed to in the subdirectory.

I've temporarily updated the path in w3tc-wp-loader.php and also copied the htaccess file into the subdirectory for testing, but that didn't solve the issue.

The issue resolves itself if page caching is turned off (while gzip and browser cache remain enabled). It also does not occur when page caching is enabled and gzip in the browser cache turned off. This leads me to believe it has something to do with the combination of the the two.

Lastly, the issue does not occur when debugging (page and database) is turned on, while everything else is still enabled.

http://wordpress.org/plugins/w3-total-cache/