There are three ways to reasonably serve up RSS, listed here in order of preference:
application/rss+xmlapplication/xmltext/xml
Since the first is the type we say we’re serving in the link tag (despite that type not being a real MIME type), that is the one we should probably pick to serve our feeds as. The problem is that browsers (rightly) refuse to display application/rss+xml. Instead, they try to download it or pass it to another viewer.
This behaviour doesn’t help someone who doesn’t know what an RSS feed does (a problem that needs addressed). They will see something they do not understand being downloaded and abort. Not good. To aid in this, it would be nice for the user to see the styled feed (my RSS 2.0 feed already has CSS styling).
Two thoughts occurred to me: “Are there any workarounds?” and “How are others serving their RSS feeds?”.
Changing the content-type to application/xml fixes the visibility problem, but means that feeds are inconsistent with the link tag. In turn, changing the link tag to suit the new content-type isn’t feasible. There are dozens of aggregators who need to see application/rss+xml in the link tag to do auto-discovery properly.
Step 2 was to see how others serve their feeds. The results were disconcerting, at best. Jacques Distler and Anne van Kesteren both use text/xml, Mark Pilgrim uses application/xml, and Sam Ruby uses application/xml for RSS 0.91 and application/rss+xml for RSS 2.0.
Ouch.
In the end, it’s probably best to settle on the middle option: application/xml. Why? It provides visibility, is the parent of the “correct” MIME type (if you see these things as hierarchical), and it is a real MIME type.
The situation is hardly ideal, but it’s the one we have.
As an aside, my RSS feeds now have a new extension (.rss, rather than .xml). I’ll be doing a transparent redirect for now, in a month or so I’ll make it explicit, and a month after that I might remove the old style entirely. Please update your subscriptions now to avoid disappointment later.