304917 - Permanent Redirect from an RSS feed should update the stored URL

Status: RESOLVED FIXED

(MailNews Core :: Feed Reader, enhancement)

Description

[Trejkaz]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716 Firefox/1.0.6

If I add a feed today, and in the future the site admin moves the feed URL
permanently, Thunderbird should update the stored URL to the new location.

Reproducible: Always

Steps to Reproduce:

Actual Results:  
Thunderbird follows the redirect but does not update the configuration to store
the new URL.

Expected Results:  
Thunderbird should store the new URL so that next time, the old URL isn't even
requested.

Comment 1

[Jamie Thompson]

I'd like to vouch for this too. I've been wondering why my Slashdot RSS feed hasn't worked for awhile and I just fired up Wireshark and noticed the 301 redirect...which itself doesn't seem to be working.

Comment 2

[alta88]

Automatically updating the feed url on a 301 is not a good idea for these reasons:
1. Through malice or error, a 301 can be sent causing dataloss, as has been described in the airport/hotel wifi scenarios.
2. The end user/publisher is not guaranteed to have/be given access to create a 301 redirect rule in .htaccess thus resulting in 'capture' by a bad hoster.

In addition, the xhr api currently used would have to be reworked using a channel to get the 301 result, as the current method gets the already redirected url from gecko without knowledge of an underlying 301.

However, there exist 2 methods, on an higher level in the stack, to accomplish a permanent update more safely and with complete publisher control:
1. The rss2.0 <redirect> document's <newLocation> tag [1].
2. The <itunes:new-feed-url> tag [2].

This patch implements both of the above two methods.

[1] http://www.rssboard.org/redirect-rss-feed
[2] http://www.apple.com/itunes/podcasts/specs.html#newfeed

Comment 3

[alta88]

Attachment: redirectTag.patch

Comment 4

[Magnus Melin [:mkmelin]]

Comment on attachment 8465613 [details] [diff] [review]
redirectTag.patch

Review of attachment 8465613 [details] [diff] [review]:
-----------------------------------------------------------------

Looks ok to me. r=mkmelin

::: mailnews/extensions/newsblog/content/FeedUtils.jsm
@@ +495,5 @@
> +                             .QueryInterface(Ci.nsIRDFResource);
> +    aFeed.title = title;
> +    aFeed.link = link;
> +    aFeed.quickMode = quickMode;
> +    aFeed.options = options;

is it really necessary to set these again?

Comment 5

[alta88]

(In reply to Magnus Melin from comment #4)
> Comment on attachment 8465613 [details] [diff] [review]
> redirectTag.patch
> 
> Review of attachment 8465613 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> Looks ok to me. r=mkmelin
> 
> ::: mailnews/extensions/newsblog/content/FeedUtils.jsm
> @@ +495,5 @@
> > +                             .QueryInterface(Ci.nsIRDFResource);
> > +    aFeed.title = title;
> > +    aFeed.link = link;
> > +    aFeed.quickMode = quickMode;
> > +    aFeed.options = options;
> 
> is it really necessary to set these again?

the way it works is that the feed is run through deleteFeed() so feeditems are also cleaned up, otherwise it would be simpler to use an rdf Move().  since the whole thing is deleted, using the aFeed setters is what actually adds those to rdf for the new url resource/subject key.  (a Move() is just a delete/add under the covers anyway).

btw, this will be documented in the feed support article.

Comment 6

[Patrick Cloke [:clokep]]

https://hg.mozilla.org/comm-central/rev/8df7f483269e

Comment 7

[drm]

I have subscribed to a podcast that uses itunes:new-feed-url to redirect itunes users use m4a format files rather than mp3. Not being an ipod user, this is a problem for me. https://support.mozilla.org/en-US/questions/1080801#answer-776283 The publisher claims that Thunderbird's use of this tag is non-standard, and I agree. Could there at least be an option to turn off this behavior?