[Project_owners] feed:// URLs?

[Eric H. Jung]

--- Neil <neil at parkwaycc.co.uk> wrote:

> Here's a more complete answer that Phil Ringnalda gave me:
> 
> feed: URIs started to solve two problems - that a link to a feed just 
> showed "an incomprehensible spew of XML" to people who clicked on it 
> without a handler installed for the mimetype (in the rare case where the 
> mimetype was anything even vaguely right, since only Atom has a 
> registered mimetype and most RSS is served with something random and 
> utterly wrong, like text/plain or text/html), and that even if you have 
> a feed reader installed that's registered as a handler for some 
> IETF-unregistered and unregisterable type like application/rss+xml, 
> content-type handlers don't get the URI, they get a local copy of the 
> contents, and RSS doesn't have an element whose contents are "the URL 
> for me." So in the days before any browsers recognized and did anything 
> with feeds, linking to feed://example.org/myfeed/ instead of 
> http://example.org/myfeed/ would let feed readers that knew to register 
> a handler for feed: successfully subscribe, since they would get the 
> URI, and would tell people without one that there was no point in 
> clicking the link.
> 
> Of course inventing a non-protocol protocol because people don't use 
> mimetypes properly, and because you don't like the content of your 
> format, is completely contrary to WebArch and it will never be 
> registered and really shouldn't have been done, but it's done and in the 
> wild. Whether or not it currently does I don't know, but for several 
> years the default feed links in WordPress were feed: URIs, so there are 
> several million links with @href starting feed:// on the web.
> 
> Then the oddly named version of Safari named for a single feature, 
> Safari RSS, added sniffing of feeds, and they appear (from the outside, 
> I haven't looked at their code) to have decided it would be handy to use 
> feed: URIs both internally, to tell that they'd sniffed a feed, and 
> externally, in the URI they pass to a client app if you are using 
> something other than Safari as a feed reader, so that if you click on a 
> link to http://blog.mozilla.com/feed/ in Safari, it will either display 
> feed://blog.mozilla.com/feed/ as the URI for its internal feed reader 
> display, or it will send feed://blog.mozilla.com/feed/ to your default 
> feed reader.
> 
> That put Fx2 in the position of needing to do two things with feed:. 
> First, to be able to send both feed://blog.mozilla.com/feed/ and 
> http://blog.mozilla.com/feed/ to the same place, either your one true 
> feed reader or the preview page so you could decide where to send it, it 
> needed to handle feed: internally, and ignore any attempt by outside 
> apps to register for it, and second, to deal with the situation Safari 
> had produced on OS X (according to beng's comment in the code, I've 
> never tested), it needed to pass feed: URIs to client apps there, since 
> that was all they expected to get from a browser. So as far as Firefox 
> is concerned, feed://foo and http://foo with something sniffable as a 
> feed are the same thing, application/vnd.mozilla.maybe.feed until it 
> knows whether or not it can parse it as a feed, then if it can't both 
> are http://foo, but if it can both are feed://foo, since once this 
> year's version of Outlook came out only accepting feed subscriptions 
> with feed: URIs, not with http: URIs, I decided it was simpler to just 
> pass feed: URIs to local apps on all platforms, so (unless I get backed 
> out in the next few months) Fx3 is going to do that.


Wow. What a mess. I did see the comments he refers to here:
http://mxr.mozilla.org/mozilla1.8/source/browser/components/feeds/src/FeedConverter.js#373
and wondered about them, not having used a Mac this decade.

Anyway, thanks for sharing.
Eric