Comments on: Now on FeedBurner http://boredzo.org/blog/archives/2007-04-24/now-on-feedburner The personal weblog of Peter Hosey. Fri, 05 Dec 2008 13:14:02 +0000 http://wordpress.org/?v=2.6.5 By: Jeff Johnson http://boredzo.org/blog/archives/2007-04-24/now-on-feedburner#comment-32989 Jeff Johnson Sun, 29 Apr 2007 15:32:31 +0000 http://boredzo.org/blog/archives/2007-04-24/now-on-feedburner#comment-32989 We do temporarily redirect to the new URL. The new URL could break for any number of reasons, so we wouldn't want to check the old one whenever that happens. We probably should just ask the user to confirm the permanent change. However, there are difficult policy questions here in designing the UI. In the case of hotel redirects, for example, it's going to happen for all of your feeds, so we'd have to have a checkmark or something to apply the decision to all of them, otherwise you have hundreds of dialog boxes. But how long should your 'Don't ask again' decision last? If it only applies to the single refresh, then you'll get the dialog every time you refresh from the hotel, which isn't ideal. What if you're on a two week vacation? On the other hand, you don't want it to last permanently, because then you're ignoring legitimate 301's in the future. I'm certainly open to ideas, but unless someone comes up with a really good one, I'm inclined to stick with the status quo, temporarily redirecting and leaving any permanent change for the user to do manually. We do temporarily redirect to the new URL. The new URL could break for any number of reasons, so we wouldn't want to check the old one whenever that happens.

We probably should just ask the user to confirm the permanent change. However, there are difficult policy questions here in designing the UI. In the case of hotel redirects, for example, it's going to happen for all of your feeds, so we'd have to have a checkmark or something to apply the decision to all of them, otherwise you have hundreds of dialog boxes. But how long should your 'Don't ask again' decision last? If it only applies to the single refresh, then you'll get the dialog every time you refresh from the hotel, which isn't ideal. What if you're on a two week vacation? On the other hand, you don't want it to last permanently, because then you're ignoring legitimate 301's in the future.

I'm certainly open to ideas, but unless someone comes up with a really good one, I'm inclined to stick with the status quo, temporarily redirecting and leaving any permanent change for the user to do manually.

]]> By: Colin Barrett http://boredzo.org/blog/archives/2007-04-24/now-on-feedburner#comment-27399 Colin Barrett Fri, 27 Apr 2007 02:37:13 +0000 http://boredzo.org/blog/archives/2007-04-24/now-on-feedburner#comment-27399 Or, alternatively, handle the 301, but keep the previous value around so if the new URL breaks, the previous one is tried. Or, alternatively, handle the 301, but keep the previous value around so if the new URL breaks, the previous one is tried.

]]> By: Colin Barrett http://boredzo.org/blog/archives/2007-04-24/now-on-feedburner#comment-27396 Colin Barrett Fri, 27 Apr 2007 02:35:57 +0000 http://boredzo.org/blog/archives/2007-04-24/now-on-feedburner#comment-27396 What about treating 301s like 307s? (That might be what you do currently, I'm not a Vienna user). What about treating 301s like 307s? (That might be what you do currently, I'm not a Vienna user).

]]> By: Jeff Johnson http://boredzo.org/blog/archives/2007-04-24/now-on-feedburner#comment-26107 Jeff Johnson Wed, 25 Apr 2007 11:49:56 +0000 http://boredzo.org/blog/archives/2007-04-24/now-on-feedburner#comment-26107 Vienna used to handle permanent redirect, but I disabled it. The problem was that some providers of temporary internet services, such as hotels, were improperly sending out HTTP 301. Thus, Vienna users were reporting that when they traveled with their laptops, their entire subscription lists were getting wrecked, permanently redirected to the hotel URLs. We probably should implement a UI to handle permanent redirect, but until that happens, disabling it was necessary, I believe. Vienna used to handle permanent redirect, but I disabled it. The problem was that some providers of temporary internet services, such as hotels, were improperly sending out HTTP 301. Thus, Vienna users were reporting that when they traveled with their laptops, their entire subscription lists were getting wrecked, permanently redirected to the hotel URLs.

We probably should implement a UI to handle permanent redirect, but until that happens, disabling it was necessary, I believe.

]]>