UPDATE 4:45: Ricardo Galli, the author of WP-Cache, has accepted my patches and released WP-Cache 2.0.20 incorporating them (along with one other fix).
I use the WP-Cache plug-in here on the blog in case that anything I post here should get dugg/linked-listed/reddited/etc. Over on Jeff Johnson’s blog, Scott Stevenson says:
… Vienna … seems to get confused on these:
- ⋮
- feed://boredzo.org/blog/feed/atom/
This prompted me to run my Atom feed through the Feed Validator. It mentioned that I was using the “copy” named entity reference and that that was undefined; that was easy enough to fix. It also mentioned that my feed was being sent as text/html.
Wait, what?
Sure enough, curl -D /dev/stdout -o /dev/null revealed that my feed was being sent as text/html; charset=utf-8. I looked in wp-atom.php (I use Jeff Johnson’s Atom 1.0 version, in case you’re wondering), and saw that it was indeed promising application/atom+xml. Funky.
I did something or other to wp-atom.php, then reloaded the Feed Validator. Imagine my surprise to discover that — in addition to still saying text/html — it still had the “copy”-entity-reference error!
Then I remembered that I use WP-Cache, so it was retrieving a cached copy of the feed. So I went to the WP-Cache Manager and dropped the cache. OK, curl says application/atom+xml now, so I went back to the Feed Validator.
Still text/html!
I tried curl again. Sure enough, it was back to text/html. WTF?
I also noticed this other symptom: When I loaded it freshly after dropping the cache, it had a bunch of headers like “Cache-Control” and “Expires”. I didn’t know those were there. When I loaded it again (from the cache), those headers — among others — were missing.
The verdict was clear at this point: WP-Cache was eating my headers.
Further investigation confirmed the diagnosis, and several hours of even further investigation revealed the nature of the bugs (plural) that resulted in it:
- WP-Cache wanted to retrieve the headers from the response in order to cache them, but the function that it was using to do that (apache_response_headers) didn’t exist, so it (correctly) skipped over all of that code. I added code to make it use headers_list when apache_response_headers isn’t available.
- Even after I did that, WP-Cache didn’t actually store its shiny new headers anywhere because it had not yet created the description object to put them into.
I have filed two tickets, each with a patch. I’m running with both patches now, and I provide the links to them so that you may run with them too. (The second patch fixes both of the problems above; the first patch is for an unrelated bug that I fixed while I was there.)