498117 - LINK HTTP headers don't work for linking to feeds

Status: RESOLVED INACTIVE

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

Description

[Eli Grey (:sephr)]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US-Hixie; rv:1.9.0.11) Gecko/2009060309 Ubuntu/9.04 (jaunty) Firefox/3.0.11
Build Identifier: 

Currently, the LINK HTTP header support is very incomplete. As of now, it seems only to support rel="stylesheet" and type="text/css". The stylesheet is not listed under View -> Page Style. When this part of the bug is fixed, the title attribute must also be parsed. If rel="rel="alternative", the feed is not listed with the other available feeds. The title attribute will also have to be parsed when fixing that.

Reproducible: Always

Steps to Reproduce:
Case 1: Link: </style.css>; rel="stylesheet"; type="text/css"; title="Some CSS";

Case 2: Link: </feed.atom>; rel="alternative"; type="application/atom+xml"; title="News Feed"
Actual Results:  
Case 1: style.css is applied to the document but not accessible via View -> Page Style.

Case 2: "News Feed" does not appear in the feed list.

Expected Results:  
Case 1: style.css is applied to the document and is accessible via View -> Page Style.

Case 2: "News Feed" appears in the feed list.

Additional information:
http://www.w3.org/Protocols/HTTP/Object_Headers.html#link
http://www.mnot.net/drafts/draft-nottingham-http-link-header-00.txt

Comment 1

[Boris Zbarsky [:bzbarsky]]

There's no issue here with stylesheets; Elijah's testcase was just broken.

Over to feeds, in case someone wants to support feed Link headers.

Comment 2

[Phil Ringnalda (:philor)]

Not a good idea in the absence of any spec or any other browsers implementing it. Since feed autodiscovery's initial consumer was bookmarklets, and autodiscovery should still work with a locally-saved copy, I'd think the most workable approach would be to get HTML5 to say that link headers should be reflected into the DOM as though they were link elements, at which point autodiscovery wouldn't need to do anything at all.

Comment 3

[Eli Grey (:sephr)]

(In reply to comment #2)
> Not a good idea in the absence of any spec

http://www.mnot.net/drafts/draft-nottingham-http-link-header-00.txt
http://www.w3.org/Protocols/HTTP/Object_Headers.html#link

Comment 4

[Julian Reschke]

(In reply to comment #3)
> (In reply to comment #2)
> > Not a good idea in the absence of any spec

I think Phil was referring to the lack on a spec on feed discovery.

> http://www.mnot.net/drafts/draft-nottingham-http-link-header-00.txt

Updated multiple times; latest version is http://tools.ietf.org/html/draft-nottingham-http-link-header-06.

> http://www.w3.org/Protocols/HTTP/Object_Headers.html#link

That's not a spec. But http://tools.ietf.org/html/rfc2068#section-19.6.2.4 is...

Comment 5

[Masatoshi Kimura [:emk]]

(In reply to comment #4)
> > http://www.w3.org/Protocols/HTTP/Object_Headers.html#link
> That's not a spec. But http://tools.ietf.org/html/rfc2068#section-19.6.2.4
> is...
It *was* a spec, but it is obsoleted by RFC 2616 which does no longer contain the Link header.
http://tools.ietf.org/html/rfc2616#section-19.6.3

Comment 6

[Phil Ringnalda (:philor)]

No, I'm not very concerned about an autodiscovery spec, since HTML5 is now serving as one. Let me try to be clearer.

Stylesheets from link headers mostly work (though not completely, as you can see by saving http://annevankesteren.nl/test/html-element/style-header.php as "web page, complete" and then loading what you saved), because either by good fortune or by design the DOM spec said that there should be a document.stylesheets which is the One True Way to interact with linked stylesheets, from link headers or link elements or wherever.

The one way to interact with generic link elements, for feed autodiscovery or for "next" or for "made" or whatever, is the only way, getting all the link elements from the DOM and iterating through them (Firefox itself actually does that sort of sideways, by triggering from the DOMLinkAdded event, but the effect is the same except for the bugs from not noticing when one changes or is removed).

The spec I want to see is one that deals with the problem of reflecting arbitrary link headers into the DOM: it doesn't make sense to add support for using link headers for feed autodiscovery because a spec says that they should be usable for everything, when we know that they are not usable for everything, and that the support for autodiscovery will make our autodiscovery not only incompatible with that of all other browsers but also make it impossible for a bookmarklet or something acting on a saved file to have any possible way to do autodiscovery compatible with ours.

bz said on IRC that he had a sort of vague memory of it being possible to have a link header for a stylesheet which could not be expressed as a link element, that it would be impossible to implement a spec (probably HTML5, since it's more likely to say how a browser should implement Web Linking than Web Linking itself is) which said that link headers should be reflected in the DOM by just pretending that there was an equivalent link element. If that's true, I'd say Web Linking is unimplementable for a browser. If it's not true, I'd say the only proper way to fix this for autodiscovery would be to fix it for arbitrary link headers, by reflecting them into the DOM, so that autodiscovery would automatically work (and saving things with stylesheets applied by a link header would automatically work, and we could start on a whole new round of bugs complaining that save as and view selection source show something that wasn't in the HTML source).

There's also much less of a compelling reason to implement support for autodiscovery than there was for stylesheets: because stylesheets are closest-wins, it made sense to say "this lets you add a stylesheet for a whole bunch of existing HTML files without having to edit them, since to override something for just a few you can edit just those few and add a link element to another sheet, or a style element, or some style attributes, which will override the link header applied sheet." Autodiscovery is first-wins - the first linked feed is the primary feed for the page, and all of the specs say that links from link headers come before links from link elements, so for autodiscovery it's a much less useful and less flexible and less likely to work system, since all it does is give you an unobvious way to add what will become the default feed for a page with no way to override.

Comment 7

[Eli Grey (:sephr)]

(In reply to comment #6)

My main use-case for this won't even be HTML. This makes it possible to have feed-autodiscovery on non-HTML pages (ie. image/*, text/plain, xul, audio/*, video/*, etc.)

Using the LINK header for styling non-HTML pages with CSS works.

Comment 8

[Phil Ringnalda (:philor)]

Fun use case, which either needs this bug to go back to Core somewhere, or needs a dependent bug, since you need to have nsContentSink::ProcessLink fire an event that nsHTMLLinkElement will either also fire, or fire instead of DOMLinkAdded in LinkAdded and BindToTree. Then just switch Firefox over to listening to that event, and then tell anyone who uses it with HTML and then breaks a DOM user that they should have thought more deeply about what they were doing and who it would break.

Comment 9

[Tanner M. Young [:tmyoung]]

Do we want to add support for links as headers?  (Personally, as a web developer, I am in favor of it.)

If we do, where do we need to move this bug in core for it to be addressed?

Comment 11

[Mathias Bynens]

Note that the The Link header field is now defined by RFC 5988: http://tools.ietf.org/html/rfc5988

Comment 12

[BMO Automation]

Per policy at https://wiki.mozilla.org/Bug_Triage/Projects/Bug_Handling/Bug_Husbandry#Inactive_Bugs. If this bug is not an enhancement request or a bug not present in a supported release of Firefox, then it may be reopened.