[Plugin: WP Super Cache] Normal (old style) caching doesn’t seem to work anymore

  • 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.

    https://www.ads-software.com/extend/plugins/wp-super-cache/

Viewing 2 replies - 1 through 2 (of 2 total)

  • 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: https://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.

    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.

Viewing 2 replies - 1 through 2 (of 2 total)
  • The topic ‘[Plugin: WP Super Cache] Normal (old style) caching doesn’t seem to work anymore’ is closed to new replies.