Hi Thomas,

I want to thank you again for pushing me on this issue. That setting in Feedburner was exactly what I was looking for but I did not look carefully enough the first time and reading your blog post made me see it. In my defense I was looking for an input where the redirected from url would go but they had it hidden until you click a link to reveal it which made it difficult to spot that setting.

In any case I have implemented the redirect this morning and even updated this site with the latest code and so the blog on this site is using the redirect for the feed. This is also very timely because we will be making a new release of mojoPortal in the next few days and this improvement will be included. In the new implementation you don't have to setup any redirection yourself, if you enter the feedburner url in the settings that will be the default behavior and there is no need for a front door and back door feed because I was able to find the feedburner user agent string by looking in my IIS logs, so it does not redirect if the request is coming from the feedburner crawler, but does redirect all other requests.

One question I have for you about your wish list in your blog post, you mention wanting a setting to not add the auto discovery link in the head of the page. Since the new implementation adds the original blog feed url there not the feedburner url, do you still wish for that and if so why?

Thanks,

Joe

Thomas,

I will add a setting also in the blog to disable the creation of the autodiscovery link for the feed. I just realized why this is useful, if you want to hard code the discovery link in layout.master so it is on every page not just the blog then we need a way to disable it from the blog so it does not get duplicated.

Best,

Joe

Thanks Ted and Joe for working your way through this. I was intrigued by Feedburner, but as Ted said in his original post, I also didn't necessarily want to commit to it 100% without using it for awhile. To me it's really a pain when feeds I subscribe to suddenly stop working, so I wanted to avoid that for our subscribers. Now we'll be able to turn on Feedburner with the option to go back to serving the feeds internally, and not kill any subscriptions. Great job all!

Jamie

fyi, I implemented this solution with the temporary redirect bypass parameter, so now the auto discovery feed url uses the original feed url but it does not redirect until the bypass parameter changes which happens whenever the application start event fires.

I've updated this site so you can see how it works.

Best,

Joe

It is configurable on the application pool, but typically it will restart at least once a day by default settings and more commonly it will happen more frequently than once a day in shared hosting. There are a number of things that can trigger the app pool recycling by configuration, it can be based on times of day, a specific number of requests or hitting a threshold of memory usage. I think it would be a very uncommon installation that would not recycle at least once per day. You can keep an eye in your mojoportal log it logs application start and end events. I think this will be sufficient and this is easy to implement compared to any other solution I can think of for making it change periodically, but other solutions are possible so if over time we get feedback that it is not sufficient we can revisit it. In general keeping an app healthy it is good to recycle at least once a day as that clears the cache and frees up memory. The machine may have months of uptime but that is a different thing.

The only downside I can think of is a rare timing of events where the page may be rendered in the browser and then the app pool recycles and then the user clicks the discovery link it would redirect, so the very worst that could happen is a few users over time subscribing directly to the feedburner url, but this should get the vast majority of users subscribed to the local feed url and then make it redirect after the variable expires.

Best,

Joe