[Project_owners] feed:// URLs?
Eric H. Jung
eric.jung at yahoo.com
Sat Dec 15 18:45:13 PST 2007
--- 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:
and wondered about them, not having used a Mac this decade.
Anyway, thanks for sharing.
More information about the Project_owners