application/rss+xml vs. text/xml

I’ve been working on some feed support in MSDN’s new online platform (a beta of which is running and I had to decide what content-type to use when outputting a RSS feed. I knew this was a contentious issue in the past, but I thought it might have been resolved so I did some browsing of specs and discussions and ended up with the following links:

I’m sure I could find more, but it appears this was never really resolved… using application/xml seems the most ‘proper’, but the concern is that some browsers don’t know how to handle it … so the other choice is text/xml (specifically text/xml; charset=utf-8 or else the charset will default to US-ASCII). Hmm… which to choose? Even our own sites have multiple implementations:

Interestingly enough, I found one feed that used application/rss+xml (Sam’s RSS 2.0 feed) which I think is probably not the best choice since that content type was never officially registered, and it was the only feed I hit that IE didn’t understand (and therefore tried to just download).

I think I will go with “application/xml” which has the best features in my opinion.

  • It clearly indicates that this is not just text, so it should avoid issues with proxies messing with the characters,
  • it leaves the character set data in the xml declaration, avoiding a possible conflict if I specify one in the http headers that is different than what the feed specifies,
  • it displays correctly in IE and Firefox, and
  • it is consistent with what we are doing today with the MSDN main feed.

Now, what about those in-page links we have? <link rel=”alternate” type=”application/rss+xml” title=”blah” href=”rss.xml” /> …. perhaps they should be just “application/xml” as well?

Author: Duncan Mackenzie

I'm the Developer Lead for the Channel 9 team, formerly worked on MSDN as a developer, content strategist and author.

11 thoughts on “application/rss+xml vs. text/xml”

  1. Well, you should only switch the autodiscovery links in your HTML if you want them to not be discovered: there are probably a few implementations that will autodiscover a type=”application/xml” link, but many more that won’t. There’s no requirement that the type be what you actually serve: it’s an “advisory type,” not a guarantee.

    The type for the feed itself is a no-fun question, but I do have one question, as a non-MSDN member and thus non-IE7 user: do you mean that IE7 doesn’t know about application/rss+xml and insists on downloading it rather than displaying it?

  2. Serve your feeds as “Content-type: application/atom+xml”, “Content-type: application/rss+xml”, or “Content-type: application/xml”. Any of these three choices will allow you to declare your charset properly within the feed, and avoid all kinds of RFC 3023-related weirdness. All three are supported by all major feed consumers.

    Declare your charset properly in the encoding attribute of the xml declaration on the first line of the feed. Contrary to what you may have heard (cough Joshua Allen cough), getting your character encoding right is a prerequisite for producing well-formed XML.

    Link to your feeds with an autodiscovery link with type=”application/atom+xml” (this will soon be an RFC and already has a &lt;a href=”“&gt;test suite&lt;/a&gt;) or type=”application/rss+xml”. Both of these are widely supported by feed consumers. No other type values are widely recognized.

    Oh, by the way, Dave Winer knows very little about XML, even less about character encoding, and absolutely jack about media types. Ignore anything he says, you’ll live longer.

  3. Both your RSS 2.0 and Atom 1.0 feeds look fine. However, as all of the characters in these feeds are pure ASCII, there is no way to tell just by looking at the feeds whether or not you handle encoding issues properly.

    I would suggest trying the suggestions mentioned here:

    Both I&#241;t&#235;rn&#226;ti&#244;n&#224;liz&#230;ti&#248;n and “smart quotes”… note, I’m entering this from Firefox on Linux — you should try from IE6 on Windows.

  4. <p>I am working on modifying a WordPress theme right now, and I based it off their classic theme. I was looking at the feed links in the header, and for some reason, the classic theme is setup as follows:</p>
    <li>Atom 0.3-application/atom xml</li>
    <li>RSS .92-text/xml</li>
    <li>RSS 2.0-application/rss xml</li>
    <p>So I looked up the IANA MIME types, and sure enough, application/rss xml is not an official type. So I put all my RSS feeds in application/xml in the link tag. However, neither IE7 nor Firefox 2.0 does not display the feed icon for the feeds when they are linked this way. So, I guess I am going with the non-standard application/rss xml.</p>

  5. I’m finding that application/rss xml isn’t recognized by IE6, so for backwards compatibility, you should use application/xml (IE7 and FF2 recognize it just fine). It’s odd, though, because the IETF has pushed a standard through, but it isn’t in the IANA’s list of standard MIME types.

  6. Yay lets pervert html and xml into offshoot formats and protcols in an effort to lockin users to rss and podcast clients..

    This is going to be like herding cats.. This is why I don’t use any Microsoft languages.. Pervert the language, lockin the developers.. What doesn’t everyone use PHP? Obscurity is job security.

    FYI, I’m writing a web-based podcatcher.. And thinking about just open sourcing it.. So we can do away with all this xml perversion rubbish..

    Screw the rss and podcast clients.. Nobody is going to download iTunes if they can mass download files with downthemall or a plugin that might combine that and a bit-torrent..

    Send the jobs to china, see if I care, I can paint and do other things, I don’t need to be a stinkin web programmer..

Leave a Reply