- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Thu, 29 Nov 2012 02:32:56 -0500
- To: whatwg@lists.whatwg.org
On 11/29/12 2:07 AM, Gordon P. Hemsley wrote: > So perhaps a more useful question would be what to do in situations > like that—should mimesniff treat "application/octet-stream" as a type > "supported by the browser" for the purposes of sniffing images, audio > or video, fonts, or other media types? The way it works right now is that http://www.whatwg.org/specs/web-apps/current-work/#mime-types says: The MIME type "application/octet-stream" with no parameters is never a type that the user agent knows it cannot render. User agents must treat that type as equivalent to the lack of any explicit Content-Type metadata when it is used to label a potential media resource. So for the purpose of sniffing media loads specifically, that type is treated just like no type at all. But first you have to know it's a media load. > I imagine this ties in, too, to the issues with sniffing CSS files > that has been raised elsewhere: > > https://bugzilla.mozilla.org/show_bug.cgi?id=560388 > https://bugzilla.mozilla.org/show_bug.cgi?id=562377 Neither one of those has anything to do with application/octet-stream as far as I can tell. Those cover cases in which data is sent with either no Content-Type header or with such a header which can't even be parsed as "major/minor". Neither of which is true if the data says "appliction/octet-stream". -Boris
Received on Thursday, 29 November 2012 07:43:02 UTC