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
On Thu, Nov 29, 2012 at 2:32 AM, Boris Zbarsky bzbar...@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
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
On Thu, Nov 29, 2012 at 3:02 AM, Boris Zbarsky bzbar...@mit.edu 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
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
On Thu, Nov 29, 2012 at 12:57 PM, Boris Zbarsky bzbar...@mit.edu 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
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
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
because
On Wed, Nov 28, 2012 at 10:30 PM, Gordon P. Hemsley gphems...@gmail.com 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
On Thu, Nov 29, 2012 at 2:30 PM, Adam Barth w...@adambarth.com wrote:
On Wed, Nov 28, 2012 at 10:30 PM, Gordon P. Hemsley gphems...@gmail.com
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
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
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 (video and audio) loads. Note that the HTML
On Thu, Nov 29, 2012 at 1:30 AM, Gordon P. Hemsley gphems...@gmail.com 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
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
14 matches
Mail list logo