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

2012-11-29 Thread Gordon P. Hemsley
On Thu, Nov 29, 2012 at 2:30 PM, Adam Barth wrote: > On Wed, Nov 28, 2012 at 10:30 PM, Gordon P. Hemsley > wrote: >> Based on my reading of the source code, it seems that Gecko treats a >> resource served as 'application/octet-stream' as an unknown type which >> is sniffed as if no Content-Type

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

2012-11-29 Thread Adam Barth
On Wed, Nov 28, 2012 at 10:30 PM, Gordon P. Hemsley wrote: > Based on my reading of the source code, it seems that Gecko treats a > resource served as 'application/octet-stream' as an unknown type which > is sniffed as if no Content-Type was specified. > > Are there security implications with doin

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

2012-11-29 Thread Ian Hickson
On Thu, 29 Nov 2012, Gordon P. Hemsley wrote: > > The apparent contradiction occurs when, e.g., an Opus file is tagged as > "application/octet-stream". > > If I understand correctly, a UA would return "" when canPlayType() is > called against such a file—but then the file would actually play >

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

2012-11-29 Thread Boris Zbarsky
On 11/29/12 1:11 PM, Gordon P. Hemsley wrote: So... are there any additional places where "application/octet-stream" should be treated as if the media type was undefined? Or is this conversation moot now? To my knowledge, the only places in the web platform that special-case application/octet-

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

2012-11-29 Thread Gordon P. Hemsley
On Thu, Nov 29, 2012 at 12:57 PM, Boris Zbarsky wrote: > canPlayType is not called "against a file". It's called with a single > argument which is a string MIME type. If you pass > "application/octet-stream", it will return "". Its behavior does not depend > on any state of the element it's cal

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

2012-11-29 Thread Boris Zbarsky
On 11/29/12 12:45 PM, Gordon P. Hemsley wrote: The apparent contradiction occurs when, e.g., an Opus file is tagged as "application/octet-stream". If I understand correctly, a UA would return "" when canPlayType() is called against such a file canPlayType is not called "against a file". It's

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

2012-11-29 Thread Gordon P. Hemsley
On Thu, Nov 29, 2012 at 3:02 AM, Boris Zbarsky wrote: > On 11/29/12 2:53 AM, Gordon P. Hemsley wrote: >> >> 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 equiv

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

2012-11-29 Thread Boris Zbarsky
On 11/29/12 2:53 AM, Gordon P. Hemsley wrote: 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

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

2012-11-29 Thread Gordon P. Hemsley
On Thu, Nov 29, 2012 at 2:32 AM, Boris Zbarsky 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

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

2012-11-29 Thread Boris Zbarsky
On 11/29/12 2:32 AM, Boris Zbarsky wrote: On 11/29/12 2:07 AM, Gordon P. Hemsley wrote: 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 Ne

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

2012-11-28 Thread 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? Th

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

2012-11-28 Thread Gordon P. Hemsley
On Thu, Nov 29, 2012 at 1:30 AM, Gordon P. Hemsley wrote: > Based on my reading of the source code, it seems that Gecko treats a > resource served as 'application/octet-stream' as an unknown type which > is sniffed as if no Content-Type was specified. Oh, wait, I forgot what I was reading—Gecko d

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

2012-11-28 Thread Boris Zbarsky
On 11/29/12 1:30 AM, Gordon P. Hemsley wrote: Based on my reading of the source code, it seems that Gecko treats a resource served as 'application/octet-stream' as an unknown type which is sniffed as if no Content-Type was specified. Only for media ( and ) loads. Note that the HTML spec requi

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

2012-11-28 Thread Michal Zalewski
There are substantial negative security consequences to sniffing content on MIME types that are commonly used as default fallback values by web servers or web application developers. This includes text/plain and application/octet-stream. /mz

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

2012-11-28 Thread Gordon P. Hemsley
Based on my reading of the source code, it seems that Gecko treats a resource served as 'application/octet-stream' as an unknown type which is sniffed as if no Content-Type was specified. Are there security implications with doing this? Or should I add 'application/octet-stream' to the list of unk