Idle Time

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:

1. 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.
2. 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.)

• #516: Call ob_end_flush, not ob_end_clean, in phase 2 (not really relevant to the headers problem; it’s another one that’s been blogged about elsewhere)
• #517: Headers not preserved

Categories: Creations; This blog. | Comments: 3 (feed).