For those of you not familiar with RSS, I’ll describe it briefly; RSS is a particular format of XML document that is often used by sites to provide a “news feed” to subscribers, this news feed can then be read by an RSS feed aggregator, and new items on the site can easily be disseminated to describers.
HTTP, as most will recognise as the protocol we use to fetch resources when we browse the web, has some rudimentary built-in authentication facilities, and although the idea of using these with RSS is not new, it surprises me that the technique is not more widely used.
Advantages of using authentication with RSS feeds provide several possible applications: firstly, it allows sites to provide “members-only” content; secondly, it allows users of a site to select content based on their interests (provided the site had such functionality); thirdly, and of more import to sites than to users, it would allow targeted advertising to be delivered to users.
The easiest way to implement authenticated HTTP would be to respond with a 200 response upon receipt of either correct auth data, or no auth data. In the latter case, the server would send out the public RSS feed; in the latter, the server would obviously send out the private version. In the case of incorrect auth data being provided, the server responds with a 401 response, just like any other authenticated transaction.
The downside to the above method is that the user won’t be made aware if a personalised service is available. If we slightly fudge the meaning of the 401 response, we can do the following: on recepit of either incorrect auth data, or no auth data, the server responds with a 401, and the body of the document contains the public version of the feed. When the server receives correct auth data, the server sends the personalised data with a 200 response.
In this manner, the client knows if a personalised version is available, because it knows that it sent no auth data, but feed data has been received. Furthermore, it knows if personalisation is not available, since it will just receive the 200 reply if it doesn’t send any auth data.
I’m sure there are other methods of providing the same service, these just strike me as the most intuitive that don’t require separate URLs for subscribers and non-subscribers.