Feedburner Redirects

July 19, 2007

We’ve gotten a lot of complaints about RSS feeds which get redirected to Feedburner.

Usually, it happens like this: the web site you’re looking at says its RSS link is http://blah.com/rss.xml but if you were to click that link, you get a stub of html redirecting you to http://feeds.feedburner.com/blah instead, which is where the RSS really is (and no, there’s no RSS at that particular link, I’m just using it as an example, ‘k?).

So if you type http://blah.com/rss.xml into SeekSift, you’ll get back an error message saying there’s no syndicated there (because there isn’t).

Using the ultimate Feedburner address (in our little example http://feeds.feedburner.com/blah) would work, because that’s exactly the type of data we’re expecting.

The obvious thing to do is just follow the redirect, but we’re wary of making changes just for Feedburner; also, from a security perspective it’s better not to just follow, blindly, any redirect that gets presented to you.

So, for now, we ask that you figure out the actual address (and if you’ve read this far, you’ll know how to do that), but if the feedback to accommodate these Feedburner redirects continues, we’ll have to consider making a change.


3 Responses to “Feedburner Redirects”

  1. This is not about FeedBurner, this is just how HTTP works. Sometimes you request a URL and the server tells you, “Hey, it’s over at this other URL.” If you don’t like using HTTP on the web, you have a serious problem. You have to deal with all kinds of HTTP response codes, not just pretend they’re all equal to a 404.

  2. Rick Klau Says:

    Hi – thanks for posting this. Just wanted to clarify a few things:
    the redirects are implemented via HTTP redirect, not HTML redirects. Which means that any publisher redirecting blah.com/rss.xml to feeds.feedburner.com/blah is doing so at the server level, and any HTTP-compliant service should automatically follow the redirect. (Most such redirects are done via a 302 (temporary) or a 301 (permanent) redirect.) It sounds like the error that’s getting triggered is happening because the redirect isn’t being followed – but the redirect isn’t a FeedBurner thing, it’s a standard HTTP spec thing. Most often, this is being accomplished via application integration (like Blogger or TypePad) or a plugin (in the case of WordPress, Drupal, and several other apps). Publishers have been managing their redirects to FeedBurner like this for over three years, so if you guys have any questions about this, drop me a line.

    Rick Klau

  3. seeksift Says:

    From the perspective of our users, we know the redirect is something that we’ll have to do (they just want the feed, and for the most part, they could care less about any behind-the-scenes redirection or whatever we have to do to get it).

    We have no problem with the HTTP protocol, either.

    So I suppose our beef is with those content publishers who don’t use HTTP 30x for their redirects (and thanks for pointing out that it may be due to a third party tool which generates the redirect stub incorrectly; we hadn’t considered that possibility), or, more generally, simply don’t use the feeds.feedburner.com/blah format for their feed link, since that’s where it is.

    As for security, someone pointed out that limiting the number of redirects, combined with a check that the domain redirected to is indeed “feedburner.com” should reduce the chance of any serious problems.

    Many thanks for the replies.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: