The Art of Delivering an RSS Feed & How to Avoid Failing Miserably

Delivery Service vs. Self-Hosting

From a simple technical perspective, there really might be no arguments against setting up a purely self-hosted feed for your blog. However, if you're serious about your blog's success, then there might be some more requirements than just putting a simple feed URL somewhere on your website. Services like Feedburner or Feedblitz let you easily track who's interested in your content and help you retrieve statistics and measure the overall progress and success.

Don't Present the Delivery Service to Your Subscribers

When we decided to switch from Feedburner to Feedblitz, we thought about just swapping out the feed URL provided on our blog's site at first. Soon we realized that this would work for future subscribers but not for current ones.

All our readers were subscribed to the feed URL provided by Feedburner (sth. like "http://feedburner.com/tower.rss"). Therefore, we had to promote the change of our feed URL and our subscribers had to manually re-subscribe to our new feed URL. Not very elegant.

Instead of using the new feed URL provided by Feedblitz as a simple replacement, we also wanted to know if we could do better and prevent those issues in case of future migrations. Actually there are some solutions out there that look promising and each of them has its pros and cons.

4 Ways to Deliver a Feed

HTTP-Redirect via .htaccess (...Don't)

A very simple solution is to use the capabilites of your webserver (e.g. Apache) to set up a simple redirect to the feed service URL.

There are some blog posts suggesting that you should do this using a temporary redirect (HTTP response status 302). In theory, a browser would not resolve the redirect target and instead directly hand over the original URL to a feed reader.
The feed reader could then use the original URL to subscribe (e.g "http://your-blog.example.com/your-feed.xml") and only resolve the redirect target to fetch data (e.g. "http://feeds.feedblitz.com/your-feed").

A simple .htaccess example doing a temporary redirect to a remote service like Feedblitz could look like so:

RewriteEngine On
RewriteRule ^my-feed.xml$ http://feeds.feedblitz.com/my-feed [L,NC,R=302]

In practice, it turns out that this doesn't work with most of the browsers / feed readers out there. The browsers we tested won't pass the original URL to the feed readers. Even worse, doing temporary redirects often leads to problems with search engines that crawl your site and won't follow those redirects. Most SEO experts will recommend doing permanent redirects (HTTP 301) instead. Conflicting strategies...

Proxying via .htaccess

Another opportunity for hiding different feed locations from your users is to use a proxy. Again, if you use Apache as a web server and have mod_proxy enabled, you can do this with a simple .htaccess rule:

RewriteEngine On
RewriteRule ^my-feed.xml$ http://feeds.feedblitz.com/my-feed [P]

This worked great on browsers like Safari that directly delegate opening the feed to an application dedicated to consume feeds.

However, it turns out that browsers like Chrome prefer to display the feed content by themselves. No big deal?

It depends on the delivery service you're using. As said, we use Feedblitz and they actually put a link to an external stylesheet file in the feed XML. In combination with our proxying solution this violates the cross-domain request policies: A feed at "http://my-blog.example.com/feed.xml" is not allowed to reference a stylesheet at "http://feeds.feedblitz.com/feedblitz_rss.xslt". As a result, Chrome will display a blank page...

With a little bit of HTTP header tuning you can force Chrome to show up at least textual content:

RewriteEngine On
Header set Content-Type "plain/text; charset=UTF-8"
RewriteRule ^my-feed.xml$ http://feeds.feedblitz.com/my-feed [P]

Although this solution is a bit hacky, it may be an acceptable solution for some blogs.

Advanced Proxying with Content Modification

Evolving the proxying idea further, we thought about extending the proxying on the stylesheet as well. The difficulty here is to rewrite the content of the feed itself. By replacing "http://feeds.feedblitz.com/feedblitz_rss.xslt" with something like "http://your-blog.example.com/feedblitz_rss.xslt", there won't be any cross-domain policy violations.

An easy way to rewrite the content is to use a scripting language like PHP. Although this idea might look promising we almost immediately dropped it: the example above has poor perfomance, it does not yet support correct Feedblitz statistics and it's far from being ready for production. In our eyes it just makes no sense spending development efforts in feed hosting and at the same time using a feed delivery service for hosting. We wanted something simpler - that just works.

Using a Dedicated Subdomain for Your Feed

In the end we did what we knew right from the beginning would work: we set up a subdomain dedicated to serving our feed that refers directly to the delivery service. Technically, it's just a CNAME record for feeds.git-tower.com referencing feeds.feedblitz.com. Even when you aren't running your own DNS service there's a good chance that your website hosting service provides a simple web interface to set up subdomain records for your site.

Again, this works great for Safari out of the box. But what about browsers like Chrome that require the stylesheet? Luckily, Feedblitz offers you the opportunity to use your subdomain to reference the stylesheet. Just login to the blog configuration interface and go to the "RSS Settings" section. There you can enter your subdomain as the "Feed Host Name":

The result is the same as in the proxying example above, the feed XML will now link to "http://feeds.git-tower.com/feedblitz_rss.xslt" (instead of "http://feeds.feedblitz.com/feedblitz_rss.xslt") and everything will be just fine.

So why didn't we do this right from the start? This is a matter of taste and comes down to the fact that we don't like presenting subdomains to our users. Personally, we prefer using "example.com/blog" instead of "blog.example.com" and accordingly "example.com/blog/feed" instead of "blog.example.com/feed".

Therefore, we only use a subdomain for the feeds ("feeds.git-tower.com/tower-blog"), but not for the web blog itself ("git-tower.com/blog"). As some kind of positive side effect we also appreciate the fact that our web server doesn't have to handle feed traffic anymore.

Summary

From a distance, delivering an RSS feed seems like a no-brainer. However, as with many things, the devil is in the details: doing it right requires some more thinking. I hope this article can take a bit of the hard thinking off your own head.

In case you want to dive into this topic even deeper, here's a short reading list for you:

• Use a Proxy RSS URL
• Why, How and When to Quit FeedBurner
• Using Feedburner
• Let’s Say FeedBurner Shuts Down…