Feedburner URL redirection

If you have questions about using mojoPortal, you can post them here.

You may want to first review our site administration documentation to see if your question is answered there.

This thread is closed to new posts. You must sign in to post in the forums.
1/19/2011 12:00:26 PM
Gravatar
Total Posts 73

Feedburner URL redirection

Hi,

After having searched for an answer to this, I can't seem to find one, so I'll post.

I'm on mojoPortal 2.3.5.4 MSSQL.

I'm working on integrating our blogs and the feed manager with Google Feedburner.

According to Google's documentation, as well as other articles I've read on the web, the proper way to set up feedburner is to inform it of your feed(s) and then put a redirect in place on your rss address(es) so that when a client requests your feed, they are still using your url (thus maintaining your control over the client's subscription) but they are then soft redirected (302) to the feedburner url (providing you traffic offloading and analytics).

The Google document describing this setup is here.  In it, they provide an example of an Apache redirect using mod_rewrite and the [R] option, which the Apache docs describe as a 302 redirect.

When I use the Feedburner functionality in mojoPortal, however, that's not what it does.  It instead changes the RSS feed link to point directly at Feedburner's url.  This means that my users are no longer directly subscribed to my feed and I am stuck with Feedburner unless I want to lose those subscriptions should I want to migrate off of Feedburner.

Am I missing something?  How hard would it be for me to modify the setup to provide the original RSS link and a 302 redirect to FB instead?

1/19/2011 12:24:21 PM
Gravatar
Total Posts 1203
Proud member of the mojoPortal team

Help support mojoPortal!
Add-on modules

Re: Feedburner URL redirection

I agree, this sounds like it would be a very good improvement to the RSS feeds system.

1/19/2011 12:43:32 PM
Gravatar
Total Posts 73

Re: Feedburner URL redirection

Thanks Jamie.

I should also note that the Google documentation includes an exception for the feedburner client itself in the mod_rewrite rule, so that feedburner is not redirected when it tries to fetch your content!

I don't see a facility in mojoPortal to do 302 redirects (if there were, there wouldn't even need to be any special feedburner support in the blog module necessarily), and especially not with such an exception capability.

I would try to do the redirect with IIS 6 itself if the blog and feed manager links were physical files that could have their properties set, but alas since this is dynamic ASP.NET magic, I don't see how I could do that either.

So I guess I'll forgo feedburner support until we can figure this out.  That way at least our users will have the right url and will automatically start using the feedburner service once the redirects are in place.

1/19/2011 12:49:46 PM
Gravatar
Total Posts 18439

Re: Feedburner URL redirection

Hi Guys,

If we were redirecting the blog feed url to feedburner it would still result in people subscribing to the feed burner url instead of the original url because when users click the link it would take them to the feedburner url and that is what they would most likely subscribe to. Only very savvy users who don't click the feed link but right click the feed link and copy the url would be subscribing to the original url. This is what happens at most sites I've ever seen that use feedburner. Vast majority of users are going to click the link and land at feedburner and subscribe to the feedburner feed. I'm not seeing much benefit in the redirect approach for this reason. In fact the only way you are going to get subscriber stats from feed burner is if people do subscribe directly to the feedburner url and that is the primary benefit of feedburner other than some feed processing. Nothing in the feedburner documentation you linked to on google indicates that the redirect information they give is somehow allowing users to be subscribed to your original feed rather than the feedburner feed. Its just a redirect and a redirect is no better than a direct link, in fact it is better performance to not have the redirect.

If you want users to really subscribe to a local feed url but have it come from feed burner, you could create a hidden page not in the menu and add a feed manager to it, consume your feedburner url (which consumes the original blog feed url) in the feed manager then use the aggregate feed url from the feed manager to override the feed url in the blog, so users really subscribe to your aggregate feed url that is local in your feed manager but it brings the content from the feed burner ul. Then later if you decide to not use feedburner you can just change the url  in the feed manager to the original blog feed url instead of the feedburner url and it will be transparent to users. But the result again will be that in feedburner it will show like 1 subscriber because only your feed manager would be subscribed directly to the feed burner url.

Best,

Joe

1/19/2011 4:05:23 PM
Gravatar
Total Posts 73

Re: Feedburner URL redirection

Hi Joe,

Let me first genuflect a bit, since I'm going to be in some cases disagreeing with you here and I want to do so respectfully. Bear in mind, I'm new to all of this and so I'm simply trying to follow directions as opposed to trying to know it all. I just want to follow the roadmap.

I'm trying to do what is dictated by the Wise Ones(TM), who in the case of Feedburner are their docs and in the case of mojoPortal is you.

Unfortunately, I'm receiving conflicting directions here. I'm hesitant to disagree with either of you naturally, but given that FB are the experts on FB, I'm slightly more hesitant to disagree with them on this topic than with you, so forgive me for questioning your reasoning here. As a sidebar I must say that you seem pretty dismissive of their guidance, which I find surprising.

Once again, you have more experience in this than I do. At the same time, I'm not burdened by any preconceived notions, so I set out to investigate the situation given your additional guidance.

To see this in it's full process, I subscribed to new feedburner account and added a feed. It took me through the standard set of options and encouraged me to promote my new feedburner-located url. One vote for the FB url.

However, the last step tells me that I now need to have my site integrate with FB as well. As an example, I chose the Blogger directions. I happen to have a Blogger site which had not been using FB, so I set it up according to the directions.

You go into the blog settings and tell it to redirect the blog feed to FB. So far so good.

Right after that, FB has this to say:

> Blogger will now redirect all feed traffic for your blog to your FeedBurner feed.
>
> Note: If you are using the redirection feature within Blogger to send all of your feed traffic to your FeedBurner feed, you may want to modify the code we provide in order to keep your subscribers with you, even if you leave FeedBurner.

Hmm. So they definitely have something to say about the matter. Following the link, you see the following explanation:

> If I redirect my Blogger feed to FeedBurner, should I change my blog's feed chicklet links, too? Share Comment Print
If you are a Blogger publisher and you've decided to use its new redirection feature to tightly connect your Blogger blog and your FeedBurner feed, you may want to change the link to the FeedBurner feed you provide on your site when using features like Chicklet Chooser and FeedCount. Why? Portability. Let us explain:
>
> Once you redirect 100% of your feed traffic to your FeedBurner feed, you get a very complete picture of your feed-consuming audience, including where it's coming from and what content it's finding most popular in your feed. That's great. But if this audience is almost entirely subscribing to feeds.feedburner.com/myexcellentcontent, they will be stranded if, for some reason, you should choose to leave FeedBurner and revert back to your original feed address or some other service.

It goes on to say that your "Add to Google" and other reader-related "chicklets" should use the original feed url, not the feedburner one. This is very clear direction in my book. Not only this, by implication they are saying that this model works, contrary to your assertion, Joe. This is where there bears some further exposition.

Going back to the blog, the feed link still shows as the blogger address, not FB. When you click the link, it takes you to the FB url via a 302 redirect, which I verified through InternetOfficer's Redirect Checker.

At that point, there are two relevant observations. The first is that the address bar indeed shows the new feedburner address. So here is an example where you are correct Joe, if someone clicks the link directly and *then* copies the address into their reader subscription, they will have defeated the intention of keeping them subscribed to the original url.

The second observation, which I will just note here and revisit later, is that this landing page allows the owner to present a custom message to the user at this point.

So, what's going on here? Your assertion that it's possible for the user to circumvent this model is correct.

However, from having gone through the process, I would have to disagree with your assessment that this is what would happen to the vast majority of users, based on the subscription opportunities provided to the user:

1. Direct click on the feed link: This is the only way to circumvent, and requires the user to click the link. It is arguable as to what proportion of users would do this. More in a moment.

2. Right-click and copy address from the feed link: Any browser-savvy user figures this trick out pretty quickly, saving them a page-load and a copy. This does not circumvent, instead relying on the redirect.

3. Browser feed detection: All the major browsers (with the exception of Chrome, which requires an extension) support a "light up" feed indicator that detects the page feed. This is arguably the most user-friendly subscription option due to the fact that it doesn't rely on the user to even *read* the page. I always use this option, personally.

4. Reader-related chicklets: These are also a strong option since they simplify the subscription process for, by way of example, Google Reader. If my RSS detector didn't automatically add to Google Reader I might rely on these chicklets as my go-to subscription method. As the FB documentation indicates, they recommend explicitly changing from the FB url to your original one on these chicklets. This doesn't get circumvented.

Those are all of the methods I can divine. Of them, only one circumvents subscription to the original url.

While there will probably be an appreciable number of people who use it due to the fact that it is the most naive method, I would argue that it is by no means the most popular method when there are so many other options that offer concrete advantages to the user. Add to this the fact that my particular audience tends to be the savvy of the savvy (professional IT admins). Finally, for those users that *do* happen to use the "click the feed link" method, FB provides me the opportunity to inform them via the custom message that this is not the correct url and to go back and right-click for the proper address.  I intend to use this.

So I see a very real use for the redirect, as directed by FB.

As for the other assertion that using such a model would prevent FB from tracking the users, they directly contradict this in that answer which is linked above.  You still get all of the stats, which makes sense because the users are still retrieving all of the content from them, giving them all of the visibility they need.

You also raised a point about there being a performance penalty for redirecting versus sending directly to FB. I'm willing to pay the penalty for redirects (I would guess this is tiny) for the benefit of maintaining control of my users. And it's surely a smaller penalty than the re-aggregation model you proposed, which I don't find appealing.  Thanks for trying to provide an alternative though, it's appreciated.

I don't mean to sound like a jerk! Please take this feedback in the spirit of genuine inquisitiveness and constructive feedback that is intended. I love what mojo is doing for us and think it's great.

 

1/19/2011 4:07:28 PM
Gravatar
Total Posts 73

Re: Feedburner URL redirection

One other thing, in my investigation I learned that the blog module in mojo fulfills the browser feed detection requirements but the feed manager's aggrerate feed link on my site does not.  Not sure whether this is a configuration issue, bug or known issue.

1/19/2011 4:44:09 PM
Gravatar
Total Posts 18439

Re: Feedburner URL redirection

Hi Thomas,

I will research this further and see if it really is a general solution for redirecting, but this document is specifically about Blogger which is a google product so they may have tighter integration than is possible for us since they have databases connecting both their Blogger users and sites and their Feedburner users and sites.

The links in the article use urls formatted like http://fusion.google.com/add?feedurl=http://myexcellentblog.blogspot.com/feeds/posts/default so fusion.google.com somehow knows that url redirects to feedburner since the feedburner url is not passed in as a parameter, the question is do they know about a redirect coming from anywhere and that seems improbable.

The other documents you posted were workarounds for other systems to just do a redirect so if they get redirected to feedburner it seems they are going to subscribe directly to the feedburner url unless the feedburner page also somehow knows to subscribe them to the original url which it would seem you would have to enter in your feedburner account for it to do that. I have not logged into feedburner in a long time so I will check it out soon and investigate a little further, but I suspect this is a Blogger only optimization that google made available.

Best,

Joe

1/21/2011 9:51:39 AM
Gravatar
Total Posts 18439

Re: Feedburner URL redirection

Hi Guys,

From further research I find no reason to believe that redirecting is going to be better than our current implementation. This advantage that Blogger has where users can subscribe to the original feed seems to me to be something specific to Blogger that google is able to do because they control both Blogger and Feedburner and not something we can do with our feeds. If we redirect it will be no different than directly linking to feedburner and users will subscribe to the feedburner feed url.

If we try to use fusion.google.com with a feed url that is not a Blogger feed what happens is that it redirects to another google url that would allow you to subscribe to the feed in google reader or on mygoogle, but it is not for general purpose feed subscriptions, it is only for subscribing through google.

Best,

Joe

1/24/2011 4:53:51 PM
Gravatar
Total Posts 73

Re: Feedburner URL redirection

For anyone interested in making this work, I can say that it does work with the proper configuration.  It can be done without mojoPortal support, although a few tweaks to the blog module would make it easier.

I've posted directions on my blog here.

Happy mojoing.

1/24/2011 5:33:16 PM
Gravatar
Total Posts 18439

Re: Feedburner URL redirection

Hi Thomas,

It was never my intention to shut you down on this idea. I looked into it but I did not see that setting you mentioned in your blog under browser friendly settings in the feedburner settings. I'll give that a try and see what I can come up tomorrow with, that was the dot that was not connecting for me, as long as their landing page can use your local url for subscribers instead of the feedburner url it seems easily doable. Thanks for digging further on it.

Have you seen anything in their docs about how to detect the feedburner bot, like what is the user agent string for it? That would make it easy to do without 2 urls for the local feed.

Best,

Joe

1/25/2011 7:56:51 AM
Gravatar
Total Posts 18439

Re: Feedburner URL redirection

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

1/25/2011 9:32:24 AM
Gravatar
Total Posts 18439

Re: Feedburner URL redirection

Note, I have just updated the documentation for the new redirect logic

http://www.mojoportal.com/using-feedburner-with-your-blog.aspx

but keep in mind this is not in the current 2.3.5.8 release but will be in the 2.3.6.1 release coming in the next few days and it is also already in the source code repository.

Even though the current version links directly to feedburner, you could still go ahead and add the original blog url as the redirect url so that users will subscribe to your original blog url going forward, but the original url won't redirect until after upgrading to version 2.3.6.1

Best,

Joe

1/25/2011 9:42:09 AM
Gravatar
Total Posts 18439

Re: Feedburner URL redirection

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

1/25/2011 9:49:22 AM
Gravatar
Total Posts 73

Re: Feedburner URL redirection

Hi Joe,

Wow, that's very gratifying to hear your interest again.  I guess to call it interest isn't doing it justice, I can't believe you've actually implemented something so quickly.  I'm always amazed at how quickly mojoPortal gets improved to take advantage of what's going on with the web.  That's blazing fast.

Again, sorry if I sounded like a jerk at all, my only interest is making it work for my needs and trying to give that back in any way possible.  As you can see from how long the blog post was, it was definitely more involved than I thought, so I'm not surprised a brief exchange didn't give enough of the detail to see the story.  Much of my understanding changed the deeper I got, and your assessment was certainly informed, just missing an important detail as you note. I'm glad if my investigation contributes anything you and other users find useful.

As far as your notes go, that sounds on the spot by way of implementation.  The client exception makes configuration easier and that's a good thing.

For the auto-detection disabling, unfortunately, yes it's still an issue even when the link url is the correct local one.  It's because of a combination of two behaviors: first, when the user clicks the auto-detect button, the redirect is processed and shown in the addressbar as the feedburner url.  This wouldn't be so bad if the Feedburner landing page were shown, where the correct subscription buttons and the custom message were shown, but the second behavior is that IE 8 and Firefox 3 show instead their own subscription page, which strips those features.  If you subscribe at that point, you will get the Feedburner url.  There's no way to get the original url at that point.

Unfortunately, I can see no way to avoid it when using auto-detection.  It is guaranteed the user will end up with the Feedburner url using that mechanism.  It's interesting to note that it's only an issue with the auto-detect feature.  If you visit the same url directly in the browser, it properly shows the Feedburner landing page.  So it's only auto-detect that I'm concerned about.

In the case where a user isn't using Feedburner, or were using it in the non-redirected model, I'd certainly say that auto-detection is a valuable feature, so I'd just make it optional whether to use it in the redirected model.

I'll be updating my blog post to reflect the new situation.

Thanks!

Ted

1/25/2011 9:53:10 AM
Gravatar
Total Posts 1203
Proud member of the mojoPortal team

Help support mojoPortal!
Add-on modules

Re: Feedburner URL redirection

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

1/25/2011 10:05:03 AM
Gravatar
Total Posts 18439

Re: Feedburner URL redirection

Hi Thomas,

You did not sound like a jerk at all and I really appreciate the effort you went to to see all the complexities and help me see them as well.

The things you just mentioned about the problems with the auto discovery issues in various browsers was also unknown to me. It is a shame it works that way because those autodiscovery links are otherwise very useful. At least we will have a choice to disable those links but I wish there was a better solution like if there were some way to detect if the request is using the discovery link and not redirect. I can think of one solution that is not perfect but might be better than nothing.

If we had some application level variable that changes each time the application starts like a random guid, we could append that guid to the discovery url as a query string param then not redirect if it matches the current version of that variable so that the user subscribes to the local blog url with the application param as part of the querystring, but then next time the app recycles (which typically happens at least once per day) the param would no longer be valid so it would then redirect to feedburner for any future requests for that url, so only on that first day would the subscriber be seeing the un-redirected url.

What do you think? worth the effort to try this?

Best,

Joe

1/25/2011 11:55:36 AM
Gravatar
Total Posts 18439

Re: Feedburner URL redirection

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

1/25/2011 2:19:06 PM
Gravatar
Total Posts 73

Re: Feedburner URL redirection

So if I'm getting this right, you're using a rotating value on the blog url that changes every time the application is restarted.  If the request comes in with the "live" value, the request is not redirected.  Any other value is redirected, though?  Very clever.

It may be a while before the application is restarted however.  Months in my case.  It would be best if the turnaround didn't rely on an unpredictable event.  Could it issue a new value each day?

Sorry, I didn't notice you said it typically cycles once a day.  Is that a guarantee or somehow configurable?  If so I think it's a winner.

Two other thoughts:

It's still useful to be able to direct the user to a bare feed link (no value attached), especially since the value is dynamic.  In this case, I would want the redirect to be in effect so their reader subscription makes it to feedburner.  So the only time the redirect wouldn't be in effect is if they supplied the ?r= parameter but the value didn't match the live one.  [edit: sorry, I momentarily had it backwards there.  Disregard that last statement, your design already should do the right thing.]

Second, I'm curious what effect the keepalive feature has on the application recycling you mentioned.  I'm using the feature here.  Would that prevent the restart?

1/25/2011 2:35:08 PM
Gravatar
Total Posts 18439

Re: Feedburner URL redirection

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

1/25/2011 2:39:15 PM
Gravatar
Total Posts 18439

Re: Feedburner URL redirection

About the app keep alive it will not likely prevent recycling the app once per day, it will just keep the app form recycling due to no traffic which also happens by default IIS settings, after 20 minutes of no traffic by default it will shut the app down until a new request comes in.

But even with traffic coming in it should recycle at least once per day and possibly/probably more often.

Best,

Joe

1/25/2011 2:41:35 PM
Gravatar
Total Posts 73

Re: Feedburner URL redirection

Sounds like a winner to me.

1/25/2011 2:55:49 PM
Gravatar
Total Posts 18439

Re: Feedburner URL redirection

One other little goodie I forgot to mention. I still had a reason to want to disable the blog from automatically adding the feed discovery link, my reason is because I want that link on all the pages in my site not just the blog, from anywhere in the site I want users to easily be able to subscribe to the blog. So I wanted a way to be able to add the link myself in layout.master to accomplish this. I did add a new setting in the blog to turn off the automatic adding of the discovery link, then I created a new control that I could add to layout.master and it would handle adding that guid to the link for me. So in the new release you will be able to use this as well if you like, you can it to the head section in layout.master like this:

<portal:FeedDiscoveryLink id="fd1" runat="server" FeedUrl="http://www.mojoportal.com/blog19rss.aspx" FeedTitle="mojoPortal Change Blog" />

I just hard code my blog feedurl there and the control will append the query string with the guid when it renders. There is also a property on the control if one did not want to append the query string with the guid one could add this property on the control:

<portal:FeedDiscoveryLink id="fd1" runat="server" UseRedirectBypassToken="false" FeedUrl="http://www.mojoportal.com/blog19rss.aspx" FeedTitle="mojoPortal Change Blog" />

Best,

Joe

 

 

1/25/2011 8:22:41 PM
Gravatar
Total Posts 73

Re: Feedburner URL redirection

Thanks a latte, Joe!

1/26/2011 7:44:58 AM
Gravatar
Total Posts 18439

Re: Feedburner URL redirection

:-D Thank you for the coffee Ted! Much appreciated.

1/10/2012 6:59:10 AM
Gravatar
Total Posts 1

Re: Feedburner URL redirection

I am seeing some inconsistent behaviour in 2.3.6.6 when Feedburner redirection is active.

1. The Feed Discovery header does not publish the Feedburner URL, but publishes the original URL instead.

2. The link hover does not display the Feedburner URL, but displays the original URL instead.

As a workaround, I have disabled Feed Discovery header to ensure all subscribers are forced to use Feedburner, rather than end up with some random number subscribed directly.

 

1/10/2012 7:15:23 AM
Gravatar
Total Posts 18439

Re: Feedburner URL redirection

Hi,

If you read and understand this complete thread you will understand that it is working correctly. Even when using Feedburner we want people to subscribe to your original feed url not the feedburner url, so we render the original url. The original feed url will redirect to feedburner for web browser requests, but we detect the requests coming form feedburner's crawler and don't redirect them so it can consume the feed.

See also Using Feedburner with Your Blog there are settings to use to make sure that even if people are redirected to feedburner and they subscribe from there, they will subscribe to the origianl url. The whole idea is that you don't want to lose subscribers if you ever stop using feedburner so you want them to subscribe to the orginal feed url not the feedburner url.

Hope that helps,

Joe

You must sign in to post in the forums. This thread is closed to new posts.