Title: [Plugin: WP Super Cache] Gzip bug?
Last modified: August 20, 2016

---

# [Plugin: WP Super Cache] Gzip bug?

 *  [warpdag](https://wordpress.org/support/users/warpdag/)
 * (@warpdag)
 * [14 years ago](https://wordpress.org/support/topic/plugin-wp-super-cache-gzip-bug/)
 * Weird bug, looks like the new 1.1 update spits out gzip versions of cached files
   to all browsers, even the ones that don’t support gzip. It’s not obvious as most
   browsers support gzip, but it’s a bug nonetheless. Temporary fix is to disable
   compression, but that’s not the most elegant way as your traffic will increase
   dramatically. Bug verified and easy to reproduce by doing a simple curl (‘Accept-
   Encoding: gzip,deflate’ not specified yet the plugin sends a gzip version).
 * Cheers,
    David
 * [http://wordpress.org/extend/plugins/wp-super-cache/](http://wordpress.org/extend/plugins/wp-super-cache/)

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

 *  Thread Starter [warpdag](https://wordpress.org/support/users/warpdag/)
 * (@warpdag)
 * [14 years ago](https://wordpress.org/support/topic/plugin-wp-super-cache-gzip-bug/#post-2767937)
 * Note: The bug is in the new htaccess ruleset, you might not see it if you don’t
   update your ruleset with the new one. Trying to figuring it out right now.
 * Note 2: No it’s not htaccess, my bad. For some reason the plugin spits out gzip
   no matter what, I can reproduce the bug on 2 separate installs, but I can’t pinpoint
   why yet. On a third install, it works fine, odd.
 *  Thread Starter [warpdag](https://wordpress.org/support/users/warpdag/)
 * (@warpdag)
 * [14 years ago](https://wordpress.org/support/topic/plugin-wp-super-cache-gzip-bug/#post-2767951)
 * Looks like the bug is in the code itself, and is reproducible on all my installs(
   3 separate installs). Dug further, 1.1 seems to stubbornly send gzipped content
   no matter what *ONLY WHEN* the requested file is not cached yet. Once cached,
   a proper plain text file is sent for browsers that don’t support gzip, and a 
   gzipped version is sent to the ones that do.
 * If you run into this issue, my advice is to remove 1.1 and revert back to 1.0
   for now (via the developer link on the plugin page). Don’t get me wrong, the 
   plugin is great and I love it, saves me a ton of bandwidth and speeds up my site,
   but I think 1.1 needs some add’l debugging. Please contact me if you want more
   details, would love to help squash the bug once and for all.
 * David
 *  [G](https://wordpress.org/support/users/gnetworkau/)
 * (@gnetworkau)
 * [14 years ago](https://wordpress.org/support/topic/plugin-wp-super-cache-gzip-bug/#post-2768199)
 * wp-super-cache does gzip when the following option is selected:
    _Compress pages
   so they’re served more quickly to visitors. (Recommended)_
 * just an idea for you, I leave that option unselected, and allow my server to 
   do the gzip which appears a little faster. I use this in .htaccess file:
 * # Apache Server mod_deflate – Content-Encoding: gzip
    <IfModule mod_deflate.c
   > AddOutputFilterByType DEFLATE text/html text/xml text/css text/plain AddOutputFilterByType
   DEFLATE image/svg+xml application/xhtml+xml application/xml AddOutputFilterByType
   DEFLATE application/rdf+xml application/rss+xml application/atom+xml AddOutputFilterByType
   DEFLATE text/javascript application/javascript application/x-javascript AddOutputFilterByType
   DEFLATE application/x-font-ttf application/x-font-otf AddOutputFilterByType DEFLATE
   font/truetype font/opentype </IfModule>
 *  [Tats Shibata](https://wordpress.org/support/users/rewse/)
 * (@rewse)
 * [14 years ago](https://wordpress.org/support/topic/plugin-wp-super-cache-gzip-bug/#post-2768200)
 * I reproduced it, too. The below is the log of curl:
 *     ```
       $ curl -Ov http://rewse.jp/blog/index.php
       * About to connect() to rewse.jp port 80
       *   Trying 183.77.251.234... connected
       * Connected to rewse.jp (183.77.251.234) port 80
       > GET /blog/index.php HTTP/1.1
       > User-Agent: curl/7.15.5 (x86_64-redhat-linux-gnu) libcurl/7.15.5 OpenSSL/0.9.8b zlib/1.2.3 libidn/0.6.5
       > Host: rewse.jp
       > Accept: */*
       >
       < HTTP/1.1 200 OK
       < Date: Sun, 27 May 2012 08:56:11 GMT
       < Server: Apache
       < X-Powered-By: PHP/5.3.3
       < Vary: Accept-Encoding,Cookie,User-Agent
       < Cache-Control: max-age=3, must-revalidate
       < WP-Super-Cache: Served supercache file from PHP
       < Content-Encoding: gzip
       < Content-Length: 15309
       < Last-Modified: Sun, 27 May 2012 08:54:16 GMT
       < X-FRAME-OPTIONS: DENY
       < Content-Type: text/html; charset=UTF-8
       < Content-Language: ja
         % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                        Dload  Upload   Total   Spent    Left  Speed
       100 15309  100 15309    0     0  52338      0 --:--:-- --:--:-- --:--:-- 1997k
   
       $ file index.php
       index.php: gzip compressed data, from Unix
       ```
   
 * **Env:**
    - WordPress 3.3.2 ja
    - WP Super Cache 1.1
 * Thanks,
    Tats
 *  Thread Starter [warpdag](https://wordpress.org/support/users/warpdag/)
 * (@warpdag)
 * [14 years ago](https://wordpress.org/support/topic/plugin-wp-super-cache-gzip-bug/#post-2768201)
 * G – Thanks for the suggestion, appreciated, but I’m not sure we’re completely
   on the same page. I would rather have super-cache gzip the cached file directly,
   hence why I usually select the “Compress pages so they’re served more quickly
   to visitors. (Recommended)” option. IMO, it’s better to gzip it once rather than
   compress it on the fly each time it’s requested, more efficient and less load
   on the server– at least for me.
 * I noticed the bug by chance, I use my own script to prime some key pages on my
   site (I load them every so often, and in some cases I cache them myself via a
   homemade script as supercache does not handle them well), and while I was tweaking
   the script I noticed that the result of a simple curl command didn’t return text/
   html as expected, but gzip content, even if I didn’t specify gzip compression
   in the request. Only happens when the requested file is not cached, as once the
   file is cached, supercache sends a proper text/html file.
 * Tats – Thanks for confirming the bug.
 * Cheers,
    David
 *  [acrain](https://wordpress.org/support/users/acrain/)
 * (@acrain)
 * [14 years ago](https://wordpress.org/support/topic/plugin-wp-super-cache-gzip-bug/#post-2768254)
 * I can confirm this bug, and add an additional wrinkle to it. I’ve created test
   installs identical except for the version of Super Cache running; one is 0.9.9.9,
   one is 1.0 and one is 1.1. In the 1.1 install only, compressed content is returned
   regardless of the presence of an accept-encoding header.
 * In 0.9.9.9 and 1.0, output is encoded if gzip is acceptable, but is not encoded
   otherwise:
 *     ```
       $ wget --header="accept-encoding: gzip" -S -O wpsc10.html http://####/wpsc10/feed/
       --2012-05-30 14:38:50--  http://####/wpsc10/feed/
       Resolving ####
       Connecting to ####:80... connected.
       HTTP request sent, awaiting response...
         HTTP/1.1 200 OK
         Date: Wed, 30 May 2012 18:38:50 GMT
         Server: Apache
         X-Powered-By: PHP/5.3.3
         Content-Encoding: gzip
         Vary: Accept-Encoding,Cookie
         X-Pingback: http://####/wpsc10/xmlrpc.php
         ETag: "0bcd34dbc9141c29298b2563e33174ca"
         WP-Super-Cache: Served legacy cache file
         Content-Length: 804
         Keep-Alive: timeout=15, max=100
         Connection: Keep-Alive
         Content-Type: text/xml; charset=UTF-8
       Length: 804 [text/xml]
       Saving to: 'wpsc10.html'
   
       100%[=======================================================================================>] 804         --.-K/s   in 0s      
   
       2012-05-30 14:38:50 (12.1 MB/s) - 'wpsc10.html' saved [804/804]
   
       $ file wpsc10.html
       wpsc10.html: gzip compressed data, from Unix
   
       $ wget -S -O wpsc10.html http://####/wpsc10/feed/
       --2012-05-30 14:39:22--  http://####/wpsc10/feed/
       Resolving ####
       Connecting to ####:80... connected.
       HTTP request sent, awaiting response...
         HTTP/1.1 200 OK
         Date: Wed, 30 May 2012 18:39:22 GMT
         Server: Apache
         X-Powered-By: PHP/5.3.3
         Vary: Cookie
         X-Pingback: http://####/wpsc10/xmlrpc.php
         ETag: "0bcd34dbc9141c29298b2563e33174ca"
         WP-Super-Cache: Served legacy cache file
         Content-Length: 1819
         Keep-Alive: timeout=15, max=100
         Connection: Keep-Alive
         Content-Type: text/xml; charset=UTF-8
       Length: 1819 (1.8K) [text/xml]
       Saving to: 'wpsc10.html'
   
       100%[=======================================================================================>] 1,819       --.-K/s   in 0s      
   
       2012-05-30 14:39:22 (27.8 MB/s) - 'wpsc10.html' saved [1819/1819]
   
       $ file wpsc10.html
       wpsc10.html: XML document text
       ```
   
 * In 1.1, however, compressed content is returned regardless:
 *     ```
       $ wget --header="accept-encoding: gzip" -S -O wpsc11.html http://####/wpsc11/feed/
       --2012-05-30 14:49:04--  http://####/wpsc11/feed/
       Resolving ####
       Connecting to ####:80... connected.
       HTTP request sent, awaiting response...
         HTTP/1.1 200 OK
         Date: Wed, 30 May 2012 18:49:04 GMT
         Server: Apache
         X-Powered-By: PHP/5.3.3
         Content-Encoding: gzip
         Vary: Accept-Encoding,Cookie
         X-Pingback: http://####/wpsc11/xmlrpc.php
         ETag: "004bffd4c0a38ed95216e21e45e6cbc3"
         WP-Super-Cache: Served legacy cache file
         Content-Length: 805
         Keep-Alive: timeout=15, max=100
         Connection: Keep-Alive
         Content-Type: text/xml; charset=UTF-8
       Length: 805 [text/xml]
       Saving to: 'wpsc11.html'
   
       100%[=======================================================================================>] 805         --.-K/s   in 0s      
   
       2012-05-30 14:49:04 (11.7 MB/s) - 'wpsc11.html' saved [805/805]
   
       $ file wpsc11.html
       wpsc11.html: gzip compressed data, from Unix
   
       $ wget -S -O wpsc11.html http://####/wpsc11/feed/
       --2012-05-30 14:49:23--  http://####/wpsc11/feed/
       Resolving ####
       Connecting to ####|:80... connected.
       HTTP request sent, awaiting response...
         HTTP/1.1 200 OK
         Date: Wed, 30 May 2012 18:49:23 GMT
         Server: Apache
         X-Powered-By: PHP/5.3.3
         Content-Encoding: gzip
         Vary: Accept-Encoding,Cookie
         X-Pingback: http://####/xmlrpc.php
         ETag: "004bffd4c0a38ed95216e21e45e6cbc3"
         WP-Super-Cache: Served legacy cache file
         Content-Length: 805
         Keep-Alive: timeout=15, max=100
         Connection: Keep-Alive
         Content-Type: text/xml; charset=UTF-8
       Length: 805 [text/xml]
       Saving to: 'wpsc11.html'
   
       100%[=======================================================================================>] 805         --.-K/s   in 0s      
   
       2012-05-30 14:49:23 (12.1 MB/s) - 'wpsc11.html' saved [805/805]
   
       $ file wpsc11.html
       wpsc11.html: gzip compressed data, from Unix
       ```
   
 * Last, the wrinkle: The gzipped content that is returned, is unreadable. I might
   be misstating the problem, but clients receiving gzipped content (even if they
   accept gzip content, and even if the response indicates the content is gzipped)
   can’t read it. I’ve confirmed this in .NET and PHP.
 * For example the following code, reading the same 1.1 RSS feed tests above, triggers
   errors:
 *     ```
       $rss = simplexml_load_file('http://cincinnati.com/crain/wpsc11/feed/');
       print_r($rss);
       ```
   
 * …results in:
 *     ```
       [Wed May 30 14:27:33 2012] [error] [client ####] PHP Warning:  simplexml_load_file(): http://####/wpsc11/feed/:1: parser error : Start tag expected, '<' not found in /####/test.php on line 4
       [Wed May 30 14:27:33 2012] [error] [client ####] PHP Warning:  simplexml_load_file(): \x1f\x8b\b in /####/test.php on line 4
       [Wed May 30 14:27:33 2012] [error] [client ####] PHP Warning:  simplexml_load_file(): ^ in /####/test.php on line 4
       ```
   
 * Sorry for the lengthy reply–my aim is to provide as much information as possible
   to help resolve this since it means we must currently forgo gzip compression.
 * Thanks! And please let me know if I can offer any more information.
 * Andy
 *  [pioto](https://wordpress.org/support/users/pioto/)
 * (@pioto)
 * [14 years ago](https://wordpress.org/support/topic/plugin-wp-super-cache-gzip-bug/#post-2768263)
 * I reported this, with a patch, here:
 *  [http://plugins.trac.wordpress.org/ticket/1528](http://plugins.trac.wordpress.org/ticket/1528)
 *  [acrain](https://wordpress.org/support/users/acrain/)
 * (@acrain)
 * [13 years, 11 months ago](https://wordpress.org/support/topic/plugin-wp-super-cache-gzip-bug/#post-2768302)
 * FYI, this appears to be fixed in the dev version as of the time of this post.
   See [http://wordpress.org/support/topic/plugin-wp-super-cache-issue-with-scheduled-posts-not-showing-up?replies=23#post-2918753](http://wordpress.org/support/topic/plugin-wp-super-cache-issue-with-scheduled-posts-not-showing-up?replies=23#post-2918753).

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

The topic ‘[Plugin: WP Super Cache] Gzip bug?’ is closed to new replies.

 * ![](https://ps.w.org/wp-super-cache/assets/icon-256x256.png?rev=3506220)
 * [WP Super Cache](https://wordpress.org/plugins/wp-super-cache/)
 * [Frequently Asked Questions](https://wordpress.org/plugins/wp-super-cache/#faq)
 * [Support Threads](https://wordpress.org/support/plugin/wp-super-cache/)
 * [Active Topics](https://wordpress.org/support/plugin/wp-super-cache/active/)
 * [Unresolved Topics](https://wordpress.org/support/plugin/wp-super-cache/unresolved/)
 * [Reviews](https://wordpress.org/support/plugin/wp-super-cache/reviews/)

 * 8 replies
 * 5 participants
 * Last reply from: [acrain](https://wordpress.org/support/users/acrain/)
 * Last activity: [13 years, 11 months ago](https://wordpress.org/support/topic/plugin-wp-super-cache-gzip-bug/#post-2768302)
 * Status: not resolved