Redirecting RSS redirection
Sam Ruby suggests that the solution to redirecting RSS feeds is to use the rdf:about attribute of the channel item as a URL for the feed. If your feed changes URLs, just put the new URL in the old feed, and aggregators will pick it up and switch to the new URL.
A nice idea, I suppose, but completely doomed. The RSS 1.0 spec currently says that the channel rdf:about usually is “either the URL of the homepage being described or a URL where the RSS file can be found”, but that it “is a URI which identifies the channel”, nothing more. If you choose to use a URN or some other obscure form of URI, that’s perfectly legal. If you choose to use the URL of your HTML page, as I do, then you get some benefit from the RDF in RSS 1.0, since you make a few valid assertions about that page, and not just a bunch of temporary assertions about the RSS file itself.
To use the channel rdf:about as a redirect, you would first have to convince a significant percentage of the producers of RSS 1.0 that they should change to the URL of their RSS file. Given the rather large number of Movable Type users who are producing RSS 1.0 without even really realizing it, that’ll be tough. Unless you persuade most of them to switch, you’ll have to convince aggregator developers that they should try to GET the rdf:about URL whenever it isn’t the URL they are using for the feed, in case it’s a redirect, even though most of the time they’ll end up GETting (X)HTML instead of RSS. I doubt that many will be persuaded, especially since all that effort and dislocation is completely unneccesary. It’s also not very RDFish, since changing the channel’s rdf:about doesn’t say “this is in a new place now,” it says “here’s a completely different channel than the one you were expecting to find here: surprise!”
If you must reuse some existing thing, and must play nice with the keepers of the RDF flame, use mod_link, which is designed for exactly this sort of linking. Kevin designed it to be expanded with new link relationships, so I’m sure he’d be happy to incorporate l:rel="redirect". Add <l:link l:rel="redirect" l:type="application/rss+xml" rdf:resource="http://mynewurl.com/index.rss"/>, and once poor Jake gets done rewriting Radio’s namespace support to deal with a situation where a single empty element needs to be handled by different scripts based on the value of an attribute (since the handler for l:rel="redirect" can hardly be expected to also handle l:rel="service" and every arbitrary l:rel someone might add), and then everybody’s set.
Now that’s pot-stirring, not a simple little addition of the RDF namespace.
The assumption about ’all aggregators being aware’, on what are you basing that? There are programs in all sorts of environments now consuming feeds. PHP, perl scripts, modules in portals, home grown shell scripts, tons of places. Many well outside the realm of this discussion. That and the tools those environments are using may not, as is the case with Radio, give them the chance to deal with redirects, on a ’proper’ basis. If their method to retrieve the data isn’t within their direct control, as in from a module elsewhere, why assume they’d be able to fix it? They’re much more likely to be able to deal with an in-band indicator.
Be it a fringe case or not, there’s little risk to a duplicative indication. What reader that understands redirects is going to have problems with the element presense? What reader not being aware of redirects is going to have problems? The advantage of server AND in-band redirection is one of options and failsafes. Never hurts to cover your bases does it?
Yes, the overhead added to a 2.0 feed is in the form of a namespace line and checking routines. The dc namespace will doubtlessly already be present. A framework namespace line will need to be added. The looping routine that checks for the URI’s location is either in the element or a *precisely* named attribute. At this point it’s a toss up as to which is easier. If the desire is to make it /incompatible/ with a framework then embedding it in the element value will accomplish that. If it’s desirous to extend the process for both framework and non-framework environments then using the attribute placement will serve a much larger, and beneficial, goal.
The framwork driven environment can and will continue it’s efforts. It’d be nice to share those efforts with the non-framework effort. If it’s not desirous to merge the paths and eliminate confusion then this conversation is largely moot.
Hypothetically: if someone built an RSS aggregator built around RDF parsing rather than XML parsing, and then someone fed it a <foo:bazURI>http://bazurl.com</foo:bazURI>, it wouldn’t be a problem to baz with http://bazurl.com, would it? It would only be a problem if they wanted to query their existing data for other info about http://bazurl.com, right? (Assuming that they know what a foo:bazURI is, and what to do with one, already).
Phil: correct.
Sam,
Re the contrast between #1 and #7:
Since the service providers in this case are (in large part) an existing layer of infrastructure that is being repurposed to a certain degree (specifically, free web-hosting providers), we don’t really have a choice but to coddle them. The alternative is to tell the folks who are using those services ”go get a real web-host”. Nevermind that that was probably what they were trying to do which caused them to need this functionality in the first place. It’s hard enough to find an ISP that provides email forwarding after you switch providers, free web hosts aren’t going to start providing users the ability to edit an .htaccess file.
Aggregators, on the other hand, are a relatively new infrastructure layer, so from a pragmatic POV, it is easier to demand that they be built ’right’.
I fully expect that in most cases, even if a user does have enough access to use an HTTP redirect, they will probably decide to use an element instead, because it’s easier. However, I strongly feel that if a user/publisher elects to do ’the right thing’, that they should not be penalized by aggregators that do not.
Bill, regarding duplicative information, I made a mistake in reading and internalizing a couple of posts between Phil and Sam. The objection was actually to having the redirection in the new location, rather than the old one. A suspenders-and-belt approach for the old feed location does not seem to be harmful, just pointless.
Hmm.
A client that gets a 301 redirect in response to a request for the old feed won’t ever see the old feed contents. At most, a client will see a 301 response code and the contents of the new feed location, so if the client is misusing a well written library and ignoring the respose code, it needs to parse the redirection element.
This use-case explicitely requires the redirection element to be present in the new feed, making newFeedLocation not a good name. I see Sam made this point before too, but I somehow either missed it, or misunderstood it. Sorry.
But wait. If the goal is that the element should only be present if needed, the new feed cannot omit the redirection (or preferred location) element as long as a 301 redirection from an old feed location exists, if we are coddling aggregators with broken 301 support.
As Phil has noted, we keep circling around and around. The only way to break out of these arguments seems to be to declare that some form (or combination) of breakage will not be worked around, and must be fixed.
It seems to me, that if you are using a 301 redirect, the new feed location should not be required to add an element that indicates that a redirection may have just occured. Aggregators need to properly interpret the 301 response code, and publishers that can’t issue a 301 response should use a redirection element in the old location only.
I’ve withdrawn my proposal. It looks like there will be an RSS 2.0 element, used only in the old feed location for someone who can’t do an HTTP redirect, which sounds perfectly reasonable to me. There may or may not be an RSS 1.0 element/attribute/attributes at some point in the future, which may or may not appear in the old location, the new location, or both, with or without a HTTP 301. We’ll see.
Aggregator developers: I thought I saw a way to simplify your life, by encouraging a single element in a single namespace, with the only variation betweeen RSS flavors being where the actual content appeared. I failed you, and for that I’m sorry. I know you are already used to varying element names in different namespaces with different formats for the content, never mind a simple attribute versus content, but I also know how unwilling to support modules you are. Maybe next time, or the time after that.
RSS producers: I thought I saw a way to simplify your life, too, making it possible to write a single howto that would only vary a little bit between the flavors, and I really hoped to persuade people to write programs that would actually use the information that you put into your feeds. I wanted you to be able to just add something to your feed, load it in about any aggregator, and have a pretty good idea whether or not you got it right. I failed you, too, and I’m sorry.
Specturbators: I’m afraid you haven’t seen the last of me, yet, and for that you’re probably sorry.
It seems to appear not a good idea with such redirection. It’s preferably to use old scheme
why using redirected link in the latest movabletype…? The [link to bizarre spam-mirror at http://radio.wblogs.com/0100146 removed]old style[a] seems better.
Hi Phil,
Just curious as to the previous two comments. They are attributed to me but I didn’t post them.
Curious,
Rod
Redirection – He went thadda way
Dave Winer has raised the redirection issue: ”Also, I realize there’s a need for a RSS module for redirection. I
Should we expect anything different?
1. Dave Winer asks for community help deciding on a way for someone’s website syndication feed to indicate that it
HTTP 301
Phillip Pearson: 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
RDF and RSS
I’m not sure why the RDF folks keep rising to Dave’s ”Can’t we all be friends” postings. There will be no meeting ground between RDF/RSS and Userland RSS. I thought that issue had been discussed before — frequently. In particular, when I read somethin…
punch the RDF and win $20000
Guess what this means:
<admin:feedLink rdf:resource= ”http://diveintomark.weblogger.com/xml/rss.xml” dcterms:isReplacedBy= ”http://diveintomark.org/xml/rss.xml” />
Wheee, I guessed right.
But I was in the know, too.
An audacious comment spam hack
Say, Typepad hosting at wblogs.com? If I registered radio.wblogs.com, I could do something interesting with it, I bet.