When I first launched this blog I used FeedBurner to handle its RSS feed. FeedBurner is—was—a proxy that would serve your site’s RSS feed unmodified but record a bunch of analytics as it did so. (I was hosting this site on Amazon S3, which didn’t have any real way to do server-side logging or analytics.1) The way it worked was that you would publish an RSS feed at some publicly-accessible URL, point FeedBurner to that URL, and then give out FeedBurner’s proxied URL instead of your original one.
A couple of years ago I started hosting this site on a “real” web server and I no longer needed to use FeedBurner. One downside of relying on this third-party service became clear: my few subscribers had FeedBurner’s URL, not mine, saved in their feed readers. Even if I could get FeedBurner to emit an HTTP redirect—I couldn’t—my subscribers’ feed readers would probably continue to request the FeedBurner feed indefinitely.
I did the best thing I could think of, which was to point FeedBurner to a dummy RSS feed that contained a single item: a note explaining that you were subscribed to the FeedBurner version of my feed and requesting that you subscribe to the new, “real” feed instead.
A little over a year ago I figured that this notice had been available for long enough. Apparently forgetting that I could just log in to FeedBurner and delete the feed, I set my web server to give an HTTP 410 “Gone” response when the FeedBurner feed was requested. (This status code indicates that “the target resource is no longer available at the origin server and that this condition is likely to be permanent.”)
For the next twelve months, FeedBurner dutifully kept trying to fetch my dummy feed, never losing hope that the 410 Gone would one day be replaced by a beautiful 200 OK. Not only that, but when I finally remembered that I could just log in to FeedBurner and delete the damn thing, the health check told me that everything was sunny:
“Quite healthy” seems like a weird way to say “There is no feed content and I get an error when I try to request it.”
Maybe Amazon has better options now, but at the time I think the only way to log the activity on your S3 website was to have it spit out (into another S3 bucket) log files with one or two events per file. This produced an unmanageable number of files—even with my very modest traffic—and the files being stored on S3 didn’t help. ↩︎