304622 - Adding a live bookmark via feedview uses the location of the feed rather than the location given in the referring page's link element; redirects, PURLs don't work

Status: RESOLVED INVALID

(Firefox Graveyard :: RSS Discovery and Preview, defect)

Description

[Grey Nicholson (they/them)]

When a webpage provides a <link/> to a feed and gives an url that redirects to
another page, the actual location of the feed is used by the live bookmark,
rather than the url given by the <link/>.

For example:

<link rel= "alternate" type= "application/atom+xml" href=
"http://purl.org/example/newsfeed" />
(Assume http://purl.org/example/newsfeed redirects to
http://example.org/newsfeed.xml)

Using Firefox 1.0's subscription mechanism, http://purl.org/example/newsfeed
would be used as the Feed Location, as intended by the page's author.

When entering feedview, that url would be resolved to
http://example.org/newsfeed.xml; then, when adding the live bookmark,
http://example.org/newsfeed.xml would be used as the Feed Location.

If http://purl.org/example/newsfeed was then changed to redirect somewhere else
(to the newsfeed's new location), the live bookmark would break.

(Using the regression keyword because this worked as expected in 1.0.)

Comment 1

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

Not a regression; this is a feedview issue, and feedview wasn't present in 1.0.

That being said, I don't think there's a good fix for this.

Comment 2

[Grey Nicholson (they/them)]

For Atom 1.0, the href of <link rel= "self" /> could (should) be used. (Of
course, this won't fix RSS.)

Comment 3

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

When viewing a page in feedview, it's as if a normal HTML page is being viewed
in the browser.  The same thing happens if you just bookmark a normal HTML page
that you reached via a redirect.  There's no information saved about any
redirects that happened to get to that final URL, so there's no way to get that
information back when adding a live bookmark from within feedview.  There are
many times when you /wouldn't/ want to bookmark the redirect URL as well (e.g.
if you redirect through a click/link counter).

Comment 4

[Vladimir Vukicevic [:vlad] [:vladv] (needinfo me, slow to respond)]

(Whoops, hit enter too soon)

For Atom feedview could use the rel="self" link when creating a bookmark to this
page, true; just not sure if its worth fixing for atom only and causing
divergent behaviour between different RSS types when the user probably isn't
even aware of the different types.

Comment 5

[Grey Nicholson (they/them)]

The behaviour's already divergent between feeds that live behind a redirect and
those that don't. There's no way for a user to tell what url they'll arrive at
before clicking the live bookmark icon and thus no way to tell whether they've
undergone a redirect*, so the user is as unaware of the redirect as they are of
different feed formats.

rel="self" was included in Atom 1.0 for this purpose, so it ought to be used
even though it's not a proper fix.


* (except the "Waiting for..." messages in the status bar when loading the feed,
but that's only if the redirect is cross-domain)

Comment 6

[Phil Ringnalda (:philor)]

A good share of the 87,000 people using feedburner.com use temporary redirects
so they can stop using it. Feedburner does allow a month of redirecting back out
(which we'll ignore thanks to bug 275255) but other services don't. And although
I think using Atom's rel="self" rather than not throwing away the knowledge we
had when we first discovered the feed is the wrong approach, Feedburner does
include Atom rel="self" links in RSS as well as Atom.

Comment 7

[Mike Beltzner [:beltzner, not reading bugmail]]

Feedview was backed out, cleaning up deps.

Comment 8

[Tanner M. Young [:tmyoung]]

Resetting QA Contact to default.