WordPress.org

Ready to get started?Download WordPress

Forums

WP Super Cache
Gzip bug? (9 posts)

  1. warpdag
    Member
    Posted 2 years ago #

    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/

  2. warpdag
    Member
    Posted 2 years ago #

    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.

  3. warpdag
    Member
    Posted 2 years ago #

    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

  4. G
    Member
    Posted 2 years ago #

    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>

  5. Tats Shibata
    Member
    Posted 2 years ago #

    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

  6. warpdag
    Member
    Posted 2 years ago #

    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

  7. acrain
    Member
    Posted 2 years ago #

    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

  8. pioto
    Member
    Posted 2 years ago #

    I reported this, with a patch, here:

    http://plugins.trac.wordpress.org/ticket/1528

  9. acrain
    Member
    Posted 2 years ago #

    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.

Topic Closed

This topic has been closed to new replies.

About this Plugin

About this Topic

Tags

No tags yet.