Arve Bersvendsen

Migration technique for Atom: Content Negotiation

Mark Nottingham wants to discuss strategies for migration to Atom.

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:

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:

Accept: application/atom+xml,  application/rdf+xml; q=0.7,
        application/rss+xml; q=0.5, application/*+xml; q=0.2,
        text/xml; q=0,1

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 in Apache, on can then use content negotiation 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.