A quick note to the Mozilla developers responsible (you know who you are)…
And content sniffing still sucks.
§
You could add a test . . . http://lxr.mozilla.org/mozilla/source/toolkit/components/feeds/test/
is there a bug filed?
— DaveL 
Where’s the wagon? Did I fall off?
— Andrew
Ok, I’m confused, Andrew says he’s getting drunk again?
— Bob Aman
I think you’re saying that you want the developers to be assholes, right? :)
Content sniffing sucks. Failing to do content sniffing also sucks if you’re a minority browser, because the browser that most people use does it, and lots of sites rely on it. If your browser doesn’t work on at least the same sites that the most-used browser does, then people will think your browser sucks.
Think about the difference between a “web browser” and a “standards browser.” The differences lie in what users expect to happen. Browsers sniff content in a number of cases (images, rss reeds, etc) so things that things work the way users expect. Why fail to load RSS because someone didn’t configure their server right rather than just showing it to the user? Why fail to load an image because it is a JPEG and not a GIF? People don’t like seeing errors! Doing what users expect can be at odds with the standards and in cases like this standards should adjust.
No, it’s a “feed.”
— Nate
I left this comment at Ben’s, not sure it will make it through.
Here is an example of a file that is nearly identical, and will make it through the sniffer to the parser (which will then reject it and trigger a different display).
http://franklinmint.fm/2006/09/12/smedberg-atom-php.txt
The only reason the template happened to fool us is because it’s well-formed until after the root element *and* it’s in the right namespace and all that. We could probably improve the heuristic there, but this is honestly the first legitimate case I’ve seen that’s fooled both IE7 and us.
Personally, I’d evade sniffing more like this – maybe it’s just too much time spent with Mozilla code, but I think any code that doesn’t start out by telling me whose it is, and what I can do with it, just looks naked.
A full page of tri-license is a bit much, but I don’t think that 512 bytes of code and/or comment before any of the trigger elements in the world’s couple dozen example templates, so that we can catch the maybe one-fifth of all feeds served with some totally bogus mime type, is that unreasonable. It sucks, a little. Not sniffing sucks, a lot.
Mark, the problem is that over half the feeds out there have bogus MIME types, last I saw numbers. You can thank the non-browser feed readers that treat everything as a feed for that. :(
Sadly, browsers are now playing catch-up in this space and having to interoperate with the existing completely bogus content… somehow.
— Boris
I’d personally really like to see people move away from naming their feeds ‘feed.xml’ because webservers are generally much too stupid (especially now that there’s a new one cropping up every 5 minutes) to figure out that they shouldn’t be serving those files up as ‘text/xml’ or worse, ‘text/html’. I just discovered that my own feed has been being served up as ‘text/html’ for probably the last month because Rails’s caching system was written with HTML in mind, apparently. At least Rails got the encoding right. But then again, I think it probably just assumed that all text, everywhere, is utf-8. (I can’t wait to get off Rails.)
— Bob Aman
Sorry to be the Duhh-fer here. But i just dont get it.
— Mskadu
I see the source of the PHP page when i click on the link on top. Is it just me?
— Mskadu
Opera is not fooled by these files. It just shows me the plain text. And yes, Opera also does sniffing – but only for text/xml and application/xml, AFAIK. We stopped sniffing text/plain some time ago.
— Rijk
I am no longer accepting public comments on this post, but you can use this form to contact me privately. (Your message will not be published.)
§
© 2001–9 Mark Pilgrim