Phillip Pearson: There's one thing I'd like to mention: the importance that the method used doesn't require separate RSS feeds to be generated for old and new locations.
To cope with existing aggregators that understand HTTP redirects but not the new redirect semantics, we want to be able to use an HTTP 301 redirect to point from the old to the new location. However, this means that RSS fetched from both URLs will be *identical*.
This makes perfect sense to me. HTTP 301 redirect is the RESTful solution. Blog hosting services should offer it. RSS aggregators should not only follow it, but follow the instructions specified in RFC1945:
The requested resource has been assigned a new permanent URL and any future references to this resource should be done using that URL.
The problem? Some aggregators are not currently layered properly to handle this. Dave Winer indicates that Radio is one such aggregator at the moment. I suspect that this problem is widespread. Update: Dave Winer indicates that he is testing a fix! Bravo!
The solution? The solution is not to do something instead of an HTTP redirect. If there is a desire to do something in addition to an HTTP redirect, then any solution must deal with constraint that a redirect happened "under the covers" and that the feed the aggregator is actually reading is, in fact, the desired target feed.
Jon Udell seems to prefer one such solution. I describe how it would work here. Other solutions are possible.
My preference, however, would be to have HTTP 301 supported correctly on both the clients and servers.
7:26:43 AM  Comment
|
