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

On Thu, Nov 29, 2012 at 2:32 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> 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.

Oh, this is probably the location where the HTML spec doesn't
currently, but eventually should, reference the "rules for sniffing
audio and video specifically" in mimesniff. (Is this where Opera
implements such rules?)

Is it just me (and my late-night reading), or is that section
contradictory on how to treat "application/octet-stream"?

At one point it 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."

But later it says, "The canPlayType(type) method must return the empty
string if type is a type that the user agent knows it cannot render or
is the type "application/octet-stream";"

This seems to me to be unclear as to when sniffing of the audio/video
resource occurs, and what it is used for.

>> 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".

I was grouping them together because they both rely on context clues
for modifying the sniffing (fallback) behavior, but we can discuss
them separately if that's easier.

-- 
Gordon P. Hemsley
me@gphemsley.org
http://gphemsley.org/ • http://gphemsley.org/blog/

Received on Thursday, 29 November 2012 08:07:36 UTC