[whatwg] [mimesniff] Treating application/octet-stream as unknown for sniffing

[Boris Zbarsky]

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