RSS and its Discontents
November 26th, 2003
Two recent articles raising red flags about a rosy RSS future:
- Plugging the RSS Usability Hole [Link via Lockergnome's RSS Resource] re-affirms the lunacy of the little orange XML box as the primary interface to content syndication feeds. I wrote about this extensively back in the summer [chronologically: 1, 2, 3, 4, 5] Kudos to the author, David Shea of Mezzoblue, who actually does something to solve the problem: a true human-readable RSS feed. Yes, it looks like a regular web page; that’s the point. View the source, though, and you’ll see it’s just the RSS 1.0 XML file rendered via XSL and CSS.
- The End of RSS [Link via Stephen Downes' Online Learning Daily] talks about the irony of RSS success: ” Herein the black hole of RSS: If your feed works, if you are successful in attracting subscriptions on a global scale, if you do it right, you are doomed.” The problem isn’t RSS itself, but rather that much of the RSS aggregator software doesn’t properly follow protocols, downloading the feed even if it hasn’t changed, thus consuming unnecessary bandwidth. Is it any surprise that Radio Userland appears to be one of the most eggregious abusers of the protocol? Doubly ironic, since Dave Winer lodged complaints about the bandwidth burden of his feed being accessed too frequently.
Dave complained about downloaders of his feed? I missed that one ;) I only caught his mention of his RSS as being copyright and threatening action on anyone who made illegal copies, and I’ve since dropped his feed from all my aggregators. My loss, I suppose.
To be perfectly fair, although it appears none of the aggregators obey the letter of the law with regard to Conditional-GET, my recent tests and log-siftings show that most RSS feeds are probably safe: Where the CMS creates a static RSS file served by Apache, the loose rules in the Apache server will still honour the broken Conditional-GET request.
The issue is over the interpretation of Last-Modified. IETF recommends clients match this datestamp exactly, making the method virtually equivalent to matching the hash-code ETag header. Apache, on the other hand, and presumably many of the aggregators including Userland, interpret this header to mean “if later than Last-Modified“.
Thus I find that may MT RSS feeds are returning 304 codes, whereas my main Drupal site, which requires the strict exact-match interpretation of Last-Modified, fails to switch over the Conditional-GET into a 304 response for these readers.
To be completely exact, I also don’t know that these readers are not supplying the correct headers, I only know that when I manually supply If-Modified-Since to Drupal using wget, I receive the correct 304 response, and I know that when googlebot requests my back pages from that site, as with several other crawlers, they all raise 304 codes. It could be these aggregators are doing something else that Drupal doesn’t like.
I talked about using CSS to “fix” an RSS feed back in September, although I might not have been clear this is what I was referring to. ;)
http://www.tenreasonswhy.com/weblog/archives/2003/09/21/naming_rss.html#c000211
The 0.91 feed on my site has a very minimal stylesheet – I haven’t attached it to my other feeds, as currently my server doesn’t send .rss or .rdf files as XML, so browsers wouldn’t know what to do with it, anyways.
VersionTracker Does RSS (Sensibly)
I have relied for years on VersionTracker (VT) for keeping up to date with the latest updates to software or finding out about new apps for Mac, Windows, and Palm platforms. On a recent visit to another similar site (MacUpdate)…