WordPress.org

1. djr
   Member
   Posted 3 years ago #

   I think this started with the latest WP-Supercache (0.6.5), but the normal (old style) WP-Cache part doesn't seem to work anymore on my end. I had a friend of mine take a look and he offered the following bug report:

   If one uses mod_deflate and the user requesting a page accepts gzip, the stored page in ./cache is the gzipped version without a corresponding 'content-encoding: gzip' header in ./meta. Supercached pages are unaffected.

   PHP version: 5.1.6
   Apache: Apache/2.2.3 (CentOS)

   Hope this helps.

   http://wordpress.org/extend/plugins/wp-super-cache/

2. Murmatron 2
   Member
   Posted 3 years ago #

   If the Content-Encoding header is in fact missing, mod_deflate would zip the already zipped data. Some browsers don't like that very much.

   mod_deflate definitely won't encode (I checked the 2.2.9 source to verify) if a Content-Encoding header is already present in its input (it doesn't care what the encoding is claimed to be).

   However; I can't replicate the missing header in the meta.

   Here's a gzip meta from my server:

   Vary: Accept-Encoding
   Last-Modified: Tue, 29 Jul 2008 20:37:36 GMT
   Expires: Wed, 11 Jan 1984 05:00:00 GMT
   Content-Type: text/html; charset=UTF-8
   X-Pingback: http://murmatrons.armadillo.homeip.net/xmlrpc.php
   Cache-Control: no-cache, must-revalidate, max-age=0
   Pragma: no-cache
   Content-Encoding: x-gzip
   Vary: Accept-Encoding
   Content-Length: 8383

   The only strangeness there is 2 stored instances of Vary - not sure where that comes from.

   A strange problem indeed.

3. Donncha O Caoimh
   Member
   Posted 3 years ago #

   Can you disable mod_deflate? The plugin does it's own gzipping and mod_deflate doesn't store the compressed page so it actually makes your server work harder by running gzip on every request.

Topic Closed

This topic has been closed to new replies.