If you tried to go to certain WordPress sites recently you may have noticed a very strange bug. Especially if that site used WordPress 3.5 and WP Super Cache 1.2 with compression turned on and is hosted on Apache servers that don’t have mod_gzip or mod_deflate enabled. You click a link on the site and it would fail to load. Then once you refreshed it would load fine. And it would continue to load fine as long as you had been to that page on the site before. This happened to me last night when I tried to visit the Noisebridge blog, and the debugging fun began!
First I tried loading it from a different browser, then from a proxy, then from Tor Browser, then from my iPhone, to make sure it wasn’t something local to me. Other users in the #noisebridge IRC channel on Freenode confirmed they were sporadically experiencing the same problem, and one user told me that from Safari they got an error saying”‘cannot decode raw data”. Tor Browser (which I believe is simply a modified fork of Firefox) was the only browser that actually gave me a meaningful error, saying “Content Encoding Error: The page you are trying to view cannot be shown because it uses an invalid or unsupported form of compression.”
I idled for a bit pondering where to start, and finally I decided to check out the HTTP headers coming from Noisebridge’s server to see if they were telling browsers incorrect information about what form of compression to use, which yielded this:
HTTP/1.1 200 OK
Date: Wed, 23 Jan 2013 06:21:12 GMT
Server: Apache/2.2.22 (Debian)
Content-Type: text/html; charset=UTF-8
As we can see, Apache’s Content-Type was “Content-Type: text/html; charset=UTF-8″; it didn’t even send Content-Encoding. However, when I looked at the bottom of the body of the response I noticed a very conspicuous comment generated by WP Super Cache, that read as follows:
<!– Dynamic page generated in 0.442 seconds. –>
<!– Cached page generated by WP-Super-Cache on 2013-01-22 22:21:20 –>
<!– Compression = gzip –>
<!– super cache –>
From there I had a pretty good idea of what was happening. The HTTP headers informed the browser that the content was not encoded, so the browser would specifically not decode the data. But because the browser would then cache the page, subsequent browsing to that page worked fine (since you were just loading the data from your hard disk, and there were no incorrect HTTP headers for your browser to misinterpret). The immediate solution was simple – just disable compression in WP Super Cache. But I was still curious as to the root cause of the bug.
I logged in to my own server, installed WP Super Cache and played around in the Apache config until I found some relevant modules. The most probably suspects seemed to be mod_gzip and mod_deflate since those both deal with compression. Disabling either of them yielded the results I was after: As long as you had either mod_deflate or mod_gzip set up, the bug would not occur. But if you disabled both of them, the bug would occur. So there is our solution! For the 90% of you out there who don’t care about the underlying cause you can just disable compression in WP Super Cache and move on with your life. But for the 10% who will go crazy if they don’t get to the bottom of the mystery, consider this case solved.