[whatwg] Video with MIME type application/octet-stream

Andy Berkheimer andyberkheimer at youtube.com
Thu Sep 9 16:38:59 PDT 2010

Much of this discussion has focused on the careless server operator.  What
about the careful ones?

Given the past history of content sniffing and security warts, it is useful
- or at least comforting - to have a path for the careful server to indicate
"I know this file really is intended to be handled as this type, please
don't sniff it".  This is particularly true for a server handling sanitized
files from unknown sources, as no sanitizer will be perfect.

Today we approximate this through accurate use of Content-Type and a recent
addition of X-Content-Type-Options: nosniff.

Never sniffing sounds idyllic and always sniffing makes life a bit riskier
for careful server operators.  The proposals of limiting video/audio
sniffing to a few troublesome Content-Types are quite reasonable.


On Thu, Sep 9, 2010 at 3:07 AM, Philip Jägenstedt <philipj at opera.com> wrote:

> I think we should always sniff or never sniff, for simplicity.
> Philip
> On Wed, 08 Sep 2010 19:14:48 +0200, David Singer <singer at apple.com> wrote:
>  what about "don't sniff if the HTML gave you a mime type" (i.e. a source
>> element with a type attribute), or at least "don't sniff for the purposes of
>> determining CanPlay, dispatch, if the HTML source gave you a mime type"?
>> On Sep 8, 2010, at 2:33 , Philip Jägenstedt wrote:
>>  On Tue, 07 Sep 2010 22:00:55 +0200, Boris Zbarsky <bzbarsky at mit.edu>
>>> wrote:
>>>  On 9/7/10 3:29 PM, Aryeh Gregor wrote:
>>>>> * Sniff only if Content-Type is typical of what popular browsers serve
>>>>> for unrecognized filetypes.  E.g., only for no Content-Type,
>>>>> text/plain, or application/octet-stream, and only if the encoding is
>>>>> either not present or is UTF-8 or ISO-8859-1.  Or whatever web servers
>>>>> do here.
>>>>> * Sniff the same both for video tags and top-level browsing contexts,
>>>>> so "open video in new tab" doesn't mysteriously fail on some setups.
>>>> I could probably live with those, actually.
>>>>  * If a file in a top-level browsing context is sniffed as video but
>>>>> then some kind of error is returned before the video plays the first
>>>>> frame, fall back to allowing the user to download it, or whatever the
>>>>> usual action would be if no sniffing had occurred.
>>>> This might be pretty difficult to implement, since the video decoder
>>>> might consume arbitrary amounts of data before saying that there was an
>>>> error.
>>> I agree with Boris, the first two points are OK but the third I'd rather
>>> not implement, it's too much work for something that ought to happen very,
>>> very rarely.
>>> --
>>> Philip Jägenstedt
>>> Core Developer
>>> Opera Software
>> David Singer
>> Multimedia and Software Standards, Apple Inc.
> --
> Philip Jägenstedt
> Core Developer
> Opera Software
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100909/68e0a0b0/attachment-0002.htm>

More information about the whatwg mailing list