Is this feed valid? At the moment, the feedvalidator only issues a warning on the use of a text/plain mime type. At the time the feedvalidator was originally written, this was only a venial sin, primarily because browsers had no material feed support at the time, and because both desktop and web server based aggregators largely ignored the content type.
Times have changed a bit. Browsers (well, all except Chrome) support feeds now. HTML5 is taking a strong stand on text/plain (but only text/plain), and Opera and Webkit seem to be following this path. As Google has adopted Webkit for Chrome, this would imply that over time people who produce feeds such as the one mentioned above will find that such documents aren’t very interoperable.
To date, Microsoft is following a different path. Previously, Firefox had been following Microsoft’s lead in this area. It will be interesting to see what Mozilla does now that there is a fork in the road.
At the present time, I believe that this condition still only merits a warning, but over time, I can see this specific case (namely serving a feed as text/plain) being upgraded to an error.
Whatever happened to "Be strict in what you send, but generous in what you receive"? An xml feed sent as text/plain is not broken. There seems to me to be no good reason to reject it (except for religion).
The point is more whether text is a feed if it says it’s text but looks like a feed. Am I a monkey if I say I am but look human?
I’d push for an error if a feed isn’t served isn’t served as one of application/atom+xml, application/rss+xml, application/rdf+xml, application/xml, or text/xml.
@Stephen - “Be strict in what you send, but generous in what you receive” - which side of that line should a VALIDATOR fall on? I for one say the former.
Rob: thanks! Once that patch gets included in a released version of Firefox, I’ll update the feed validator.
Will this affect feeds mentioned by autodiscovery links? By that, I mean if a feed served as text plain is mentioned in an autodiscovery link, causing firefox to add a feed icon to the address bar, what happens when a user clicks on that link?
Autodiscovery is one of two ways to get preview despite being text/plain. The other is the way that autodiscovery does - under the covers, we stick a feed: in front of the autodiscovered URI, because we assume anything in a feed: URI is.
I presume you mean for clicks on a rel="feed" in content, since discovered link rel="feed" already does, and if we can ever afford to discover from a rel="feed", it would too.
Dunno. It would be cheap enough to do, but it feels a little weird, and it’s a use-case ("I don’t control the head so I can’t use link, and I’m stuck serving text/plain") that’s also met by a href="feed:...", so the only people who really need it are “... and my CMS only allows me to link to http:.” I wouldn’t object to it, but I also wouldn’t get excited about doing it myself.
Phil, are you assuming that everybody runs a recent version of Firefox? As near as I can tell, neither IE nor opera naively support the feed URI protocol.
In any case, if you want a use case of an application that the fix to bug 394416 potentially breaks, look at any planet site that provides a list of subscriptions. I run such a site, as does Mozilla. Neither of us “control the head”, and I don’t know about you, but I would much rather have the fix be “update your template” than “rewrite all the URIs to use a non-standard URI protocol that isn’t universally implemented”.
It’s tougher to justify than the fix for autodiscovery, since we definitely don’t want people clicking our feed UI and seeing text files. Worth considering, though.
You are right, it is not broken. It is a perfectly well-formed plain text document.
How are people who wish to provide example files for direct viewing as text/plain, e.g. for tutorials, to proceed in a sniffing world? Do we have to try to fool the sniffer somehow?