W3C home > Mailing lists > Public > whatwg@whatwg.org > November 2012

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

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Thu, 29 Nov 2012 02:32:56 -0500
Message-ID: <50B70FA8.9040401@mit.edu>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 30 January 2013 18:48:11 GMT