All My Brain Where stuff from my brain lands

November 8, 2007

Making WP-Super-Cache gzip compression work

Filed under: Web — Tags: , , , , , , , — Dennis @ 11:41 am

I was pretty excited to see an update to WP-Cache. The first thing I noticed is that when I enabled the new super cache compression option, I started getting a file save as dialog instead of my pages. As of the current version of WP-Super-Cache, the readme.txt file states that if you get this, you need to disable the super cache compression option.

Not being satisfied with this answer, I’ve done a little digging and come up with the following solution.

To serve gzipped pages to a browser, you have to have the following HTTP headers in the response:
Content-Type: text/html
Content-Encoding: gzip

The problem is that the default content headers that my Apache server were sending for the file extension .gz were:

Content-Type: application/x-gzip

I didn’t want to override the default types for other sites or files I may host, so I created a Location element that applies to the wp-super-cache directory:

<Location /wp-content/cache/supercache/>
AddEncoding x-gzip .gz
AddType text/html .gz

The .htaccess requirements are covered in the readme.txt file for the plugin but the options tab only shows you 1/2 of what you need. Your new .htaccess file should look like this:

<IfModule mod_rewrite.c>
RewriteEngine On
# this part handles browsers that accept gzip compression
RewriteCond %{HTTP_COOKIE} !^.*comment_author_.*$
RewriteCond %{HTTP_COOKIE} !^.*wordpressuser.*$
RewriteCond %{HTTP_COOKIE} !^.*wp-postpass_.*$
RewriteCond %{HTTP:Accept-Encoding} gzip
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{HTTP_HOST}/$1index.html.gz -f
RewriteRule ^(.*) /wp-content/cache/supercache/%{HTTP_HOST}/$1index.html.gz [L]
#this part handles browsers that don't accept gzip compression
RewriteCond %{HTTP_COOKIE} !^.*comment_author_.*$
RewriteCond %{HTTP_COOKIE} !^.*wordpressuser.*$
RewriteCond %{HTTP_COOKIE} !^.*wp-postpass_.*$
RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/supercache/%{HTTP_HOST}/$1index.html -f
RewriteRule ^(.*) /wp-content/cache/supercache/%{HTTP_HOST}/$1index.html [L]
# the original rules must follow the supercache rules
RewriteBase /
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /index.php [L]

There. All working. If it isn’t working for someone, let me know! I’ve tried recent versions of Safari, FireFox and Internet Explorer. You should be able to see the text “super cache gz” at the bottom of the source page if this is working correctly.

UPDATE: Donncha has integrated the headers into a .htaccess file inside the cache directory in the development version of the plugin. If you upgrade to that, you don’t need to make these changes and it appears to be working properly. Thanks Donncha!


  1. Man, I was having exactly the same problem. Your fix is spot on! Thank you.

    Comment by Archon810 — November 9, 2007 @ 2:36 am

  2. I actually came up with the same solution but with an extra .htaccess file in the cache folder before my initial release of the plugin, but at the time feeds were cached and the compressed feeds weren’t playing nicely with Feedburner.
    That’s all changed now as feeds aren’t cached so I can fix it again. Thanks!
    Location can’t be used in a .htaccess, so I’ll probably have to create that file in the cache folder again.

    Comment by Donncha O Caoimh — November 9, 2007 @ 2:43 am

  3. Oh yeah, did you disable the plugin? I don’t see the caching string at the end of this page, even before I left a comment.

    Comment by Donncha O Caoimh — November 9, 2007 @ 2:44 am

  4. I put the Location into vhosts.conf. It works if you have access to apache configuration files, but I’m not sure where you would put it otherwise…

    Comment by Archon810 — November 9, 2007 @ 2:59 am

  5. Hey Donncha, I still have the plugin enabled. I get the gzipped response when I telnet to port 80 and create a request with Accept-Encoding: gzip as one of the headers. You might try a different browser and look at the source. That’s how I tested it mostly since when you’re logged in you don’t get the super cache pages.

    Comment by Dennis — November 9, 2007 @ 6:32 am

  6. Actually, now that you pointed it out, I double checked the contents of my super cache directory. I’ve noticed the index page and a few posts are cached (and have gz copies) but this post, and a number of others do not have a cached copy. I noticed that after I made these comments, the cached copy of the index page was regenerated (to show the correct comment count), but still, there is no updated cached copy for this post. I’m going to try deleting the cache, and seeing what gets regenerated.

    Sure enough. After deleting the cache, the index page, meta pages (tags, categories) and a lot of older posts are getting put back into the cache. These latests two posts about wp-cache are not being stuck back in the cache though. I have no idea why this is. I’m on version 0.3.1 of WP-Super-Cache.

    Comment by Dennis — November 9, 2007 @ 6:56 am

  7. Just checking,

    This goes in the .htaccess file right?

    Comment by Baz L — November 9, 2007 @ 8:02 am

  8. Unfortunately, you have to put it in your vhosts.conf (or httpd.conf depending on your setup) if you want to use the Location element. You can Add the AddEncoding and AddType headers to their own .htaccess file in the /wp-content/cache/supercache directory though. I haven’t actually tried this but it seems like it ought to work.

    Comment by Dennis — November 9, 2007 @ 8:08 am

  9. I found out why my last two posts weren’t being cached. They had wp- in the URL, which is a rejected URL string on the cache options. I changed the slug in the post to wp_ instead for that part and it fixed the problem.

    It is sort of ironic to have a post about wp-super-cache not being cached isn’t it.

    Comment by Dennis — November 9, 2007 @ 8:24 am

  10. Update your plugin and change the “wp-” to “wp-.*.php”
    It now uses preg_match instead to match strings 🙂

    Comment by Donncha O Caoimh — November 9, 2007 @ 8:44 am

  11. Did you mean update to a new plugin version? I still see 0.3.1 as the latest. If I change the wp- in the current version will it break?

    Comment by Dennis — November 9, 2007 @ 10:03 am

  12. Never mind Donncha, saw your post on the WordPress plugin page about the changes being in trunk.

    I think the development version is right on! Thanks.

    Comment by Dennis — November 9, 2007 @ 10:25 am

  13. Super cache compression is working. Wp-cache is caching files and storing them in the cache directory. The only files being cached according to the listing is feeds and print files.

    Anyone know why the other page loads are not being cached. There is no indicator at the bottom of the source file about wp-cache, just compression even when reloaded.

    Thanks for the help

    Comment by bushtool — January 27, 2008 @ 4:14 pm

  14. Thanks, did the same thing on my blog. Firefox figures out the page is HTML despite the gzip HTTP header, but Internet Explorer gets confused and prompts you to download the site. The .htaccess file in the cache directory fixes the headers.

    Comment by Richard X. Thripp — June 22, 2008 @ 7:02 pm

  15. Hi Dennis, I’m having some trouble buddy. I’m able to run Super-Cache properly (as long as GZip is not enabled) on IE6 and IE7; however, once it’s enabled, it asks me to download the page. I tried following your aforementioned code, but it results in the website not even loading on IE6/7. I pasted the “” code in my /cache/.htaccess folder and the “<IfModule mod_rewrite” code in my main .htaccess under my public_html folder. When I made these modifications, the site still works on Safari and Firefox, but not Internet Explorer. Let me know if I overlooked something.

    Comment by Rishi Kumar — July 11, 2008 @ 4:47 pm

  16. Best I can recommend is using telnet to grab your web page and examine the exact headers that are being sent/received. Or you could try tcpdump or something. You’ll have to determine which header is missing or incorrect.

    Comment by Dennis — July 12, 2008 @ 1:40 pm

  17. Hi! It does not work on Litespeed servers 🙁

    I geuess the suspect is:
    AddType text/html .gz

    as the pages are rendered as garbage text under IE. Such a pitty, unless there is a solution.

    Comment by error12 — July 31, 2008 @ 3:34 pm

  18. Oh, it’s solved now. Litespeed compresses the files anyway.

    Comment by error12 — August 1, 2008 @ 4:16 am

  19. Recently moved servers from StartLogic to HostGator. Having a problem with WP-Cache. I know how to set it up. I know about permissions. It just would not work on HostGator (even though others have it working).
    Then I found SuperCache and decided to try it. Funny. SuperCache works for IE. And for FireFox- on my other machines, but not my Toshiba laptop. I just completely removed Firefox and reinstalled – same thing.
    Any ideas?

    Comment by Buck — August 15, 2008 @ 4:44 pm

  20. Install FireBug (Plugin) and see what headers are being returned. You can use Telnet to debug the raw information returned too.

    Comment by Dennis — August 15, 2008 @ 6:39 pm

  21. […] I posted an update that deals with getting the super cache compression to […]

    Pingback by WP Super Cache – The Ultimate WordPress Caching Plugin | All My Brain — January 16, 2010 @ 8:08 am

RSS feed for comments on this post. TrackBack URL

Leave a comment

Powered by WordPress

%d bloggers like this: