다음을 통해 공유


Publisher's Guide Update with MIME Detection

We’ve updated the Publisher’s Guide (https://blogs.msdn.com/rssteam/articles/PublishersGuide.aspx) with how IE7 detects if a file is a feed.  If you publish feeds, make sure that your site’s feed is detected and readable in IE7.

If a user browses to a feed though the feed discovery button on the CommandBar, IE7 assumes it is a feed and applies the feed reading view.

When a user clicks on a link to a feed, IE7 uses the MIME Content-Type information to determine if it is a feed.  Here is a list of recommended MIME Content-Types:

RSS 2.0 (.91 and .92): use text/xml (recommended) or application/rss+xml
Atom 1.0: use application/atom+xml
RSS 1.0: use application/xml or text/xml

For generic Content-Types (ex: “text/xml” and “application/xml”) IE7 reads the file and looks for specific strings to determine if it is a feed.  For details, please read the Publisher’s Guide.

Let us know if there are any issues with our implementation.  For sites that follow the guidelines but are not properly detected in IE7 Beta 2 Preview, please post the site on our wiki.
 
- Jane

Comments

  • Anonymous
    March 30, 2006
    So, in essence, it will no longer be possible to apply a xslt stylesheet to an RSS feed. That 's not so important, but I had a bunch of ideas for OPML, so I'd be sad if you used the same type of "forced control" on it in the future.
    Could it be possible to default to use a stylesheet if it is present, and go to feed reading view only if it is a RSS feed AND no stylesheet is present?

    Thanks
  • Anonymous
    March 30, 2006
    Why should an RSS 1.0 feed not use application/rdf+xml? That would seem perfectly reasonable considering that the RSS in RSS 1.0 stands for "RDF Site Summary".
  • Anonymous
    March 30, 2006
    Do you have any particular reason for recommending text/xml over application/xml? I know that the MS XML stack refuses to admit that RFC 3023 exists, and I really don't care, but because there are other implementations that do care, and will treat what would otherwise be well-formed XML as not-well-formed if served as text/xml without a charset param on the content-type header, it seems like needlessly bad advice.
  • Anonymous
    March 30, 2006
    Phil:
    For RSS 2.0, we're basically following Dave's recommendation (http://blogs.law.harvard.edu/crimson1/2004/05/06) and common practice (e.g. http://www.cadenhead.org/workbench/news/2717/choosing-official-rss-mime).

    I understand the rationale for recommending application/xml, but perhaps this is something that the RSS Advisory Board should take up?

    I'll post to the rss-public list.

    - Sean
  • Anonymous
    March 30, 2006
    James:
    We avoided application/rdf+xml because we wanted to avoid interfering with any registered mime-handlers for RDF content.

    For background:

    text/xml and application/xml are traditionally handled by the browser (and are already considered "ambiguous" by the browser, so scanning the content to figure out how to handle it is not a fundamental change in functionality).

    application/rss+xml and application/atom+xml are specific enough that we considered it acceptable (as an RSS reader) to handle those directly.

    application/rdf+xml is neither traditionally handled by the browser, nor specific to the RSS 1.0 usage. As such, we don't want to change how that mime-type is handled without a specific need.

    It appears, however, that there are few, if any, RSS 1.0 feeds that use application/rdf+xml, so its not a problem. If that changes, we will consider moving application/rdf+xml to "ambiguous". Ambiguous handling means that we assume that the mime-type means multiple things (we do this today for text/plain and application/octet-stream, for example). So we would then handle it ourselves first, scan it to figure out if it's an RSS 1.0 feed, and hand it off to a registered mime handler only if we decide its not an RSS 1.0 feed.

    On the whole, however, I'd prefer to keep the status quo and use application/xml or text/xml for RSS 1.0, because its far simpler for us (given that we have to do scanning of those mime-types for RSS 2.0 feeds anyway).
  • Anonymous
    April 01, 2006
    This link in the story "feed discovery button" does not work when going thru Bloglines, and I thought it was just an anti-FF link lol.
  • Anonymous
    April 07, 2006
    Thanks for this information, I'll implement it for BDN as well (newsfeed site listed in my URL). Can you tell me why no one appears to be supporting OPML instead of putting a whole bunch of <link entries in your header section? A link to one opml file seems a lot cleaner and easier to maintain (particularly with the way ASP.NET controls work today) than having to put a link entry in for EACH rss file you have.
  • Anonymous
    April 10, 2006
    I ask the same question as Matt Terenzio - will it no longer be possible to apply XSLT to an XML-feed and have it showed in sthe way specified?

    I myself would prefer if IE 7 choosed to view the site with the specified XSLT-stylesheet and show in one way or another for the user that it's a feed and give them the option to do whatever you want them to be able to do with it.

    Why would I prefer this? Well IE 7 is above all a webbrowser and therefore should emphasize the webrendering of XML-files. I want to be able to use a styled XML-file as my webpage and I want to be able to know that people will be shown that site and not only my texts from within that site. To not show them that is to work against an evolvement into a semantic web...
  • Anonymous
    April 26, 2006
    I didn't notice until Ben borrowed the same heuristic for Firefox, but why when you are sniffing for RSS 1.0 do you check for both "&lt;rdf:RDF" and the RDF namespace URI? I would guess that the set of things with one and not the other is empty, or at the very least vanishingly small compared to the unchecked set of thing with the string "&lt;feed" but without an Atom namespace URI.