Eric H. Jung wrote: >Are feed:// URLs supposed to be handled internally by firefox and not result >in a new HTTP request when followed? If so, how are feed URLs generated (I >don't see websites using them AFAIK). > > 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. _______________________________________________ Project_owners mailing list [email protected] https://www.mozdev.org/mailman/listinfo/project_owners
