[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
-
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.
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
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>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,
TatsG – 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,
DavidI 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
I reported this, with a patch, here:
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.
- The topic ‘[Plugin: WP Super Cache] Gzip bug?’ is closed to new replies.