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
