“Mark Nottingham”:http://www.mnot.net/blog/ wants to discuss strategies for “migration to Atom”:http://www.mnot.net/blog/2004/02/15/syndication_migration.
At this point, I’d like to point out that HTTP already provides a perfectly working mechanism for serving the correct content based on what the aggregator sends as mimetype. HTTP/1.1 defines the “Accept header”:http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.1:
bq. The Accept request-header field can be used to specify certain media types which are acceptable for the response. Accept headers can be used to indicate that the request is specifically limited to a small set of desired types, as in the case of a request for an in-line image.
How is this applicable to Atom and RSS? Let’s say you have your newsfeed at /index/mainfeed. A well-behaved, modern aggregator following the HTTP/1.1 specification could send an Accept header with the request:
bc. Accept: application/atom+xml, application/rdf+xml; q=0.7,
application/rss+xml; q=0.5, application/*+xml; q=0.2,
Which roughly translates to the client saying
I prefer to have this document in Atom format, if that is not available, my next choice is RSS 1.0, and finally, if you have neither, I would like RSS 0.91/2.0. Should any of these fail, give me anything you’ve got at this URL with an application/*+xml mimetype, and finally, try text/xml.
Using something like “mod_negotiation”:http://httpd.apache.org/docs-2.0/mod/mod_negotiation.html in Apache, on can then use “content negotiation”:http://httpd.apache.org/docs-2.0/content-negotiation.html to serve the right content to the client; if it’s a client that groks and prefers Atom, let the server choose the Atom version. If it’s something else, use whatever that “else” is.
This last point also raises a question: There are a lot of older aggregators out there, and some (many) of them probably won’t send an Accept-header. How should this be handled? Suggestions welcome.