WordPress 1.0.2's default RSS/Atom templates seem perversely insistent on preventing the standard techniques to minimize network traffic from repetitive polling by news-readers. In particular, the templates defeat all attempts by clients to use if-modified-since or etag: headers.
This is going to annoy high-profile bloggers [of which I am definitely not one] because their servers and pipes will get hammered by constantly sending out feed data to people's news readers.
So here's what's wrong:
* The HTTP headers in the response disable caching and return the current time as the last-modified date: (this fetch was done at 9:25 AM PDT.)
Cache-Control: no-store, no-cache, must-revalidate, post-check=0, pre-check=0
Expires: Mon, 26 Jul 1997 05:00:00 GMT
Last-Modified: Thu, 22 Apr 2004 16:25:54 GMT
* Using an If-Modified-Since: header in the client's request doesn't work, the server sends back a 200 status and the whole document, instead of a 304 "Not Modified".
* The client can't even optimize its own CPU usage by ignoring the result if the contents are identical to what it last received, because they're always different! There is a <pubDate> tag in the feed that contains the date the page was fetched, so any two consecutive fetches will return different data.
I think the first two things are side effects of WordPress using PHP, which by default generates dynamic pages that shouldn't be cached. The third one is the fault of the template, but probably what's going on is that WP doesn't have a good sense of when the feed contents might have last changed — the template should probably be using the mod date of the latest post that will be returned.
Alternatively, WP could generate the newsfeed as a static file, regenerating it automatically whenever a post is added or modified. That would save additional CPU time since there would be no PHP activity when news readers poll the feed, just a quick 304 return by the server most of the time.
I'm still on 1.0.2. Is any of this fixed in WP 1.2?