Much of this discussion has focused on the careless server operator.  What about the careful ones?<div><br></div><div>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.</div>

<div><div><br></div><div>Today we approximate this through accurate use of Content-Type and a recent addition of X-Content-Type-Options: nosniff.</div><div><br></div><div>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.</div>

<div><br></div><div>-Andy</div><div><br><div class="gmail_quote">On Thu, Sep 9, 2010 at 3:07 AM, Philip Jägenstedt <span dir="ltr"><<a href="mailto:philipj@opera.com">philipj@opera.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">

I think we should always sniff or never sniff, for simplicity.<br><font color="#888888">
<br>
Philip</font><div><div></div><div class="h5"><br>
<br>
On Wed, 08 Sep 2010 19:14:48 +0200, David Singer <<a href="mailto:singer@apple.com" target="_blank">singer@apple.com</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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"?<br>


<br>
<br>
On Sep 8, 2010, at 2:33 , Philip Jägenstedt wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On Tue, 07 Sep 2010 22:00:55 +0200, Boris Zbarsky <<a href="mailto:bzbarsky@mit.edu" target="_blank">bzbarsky@mit.edu</a>> wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 9/7/10 3:29 PM, Aryeh Gregor wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* Sniff only if Content-Type is typical of what popular browsers serve<br>
for unrecognized filetypes.  E.g., only for no Content-Type,<br>
text/plain, or application/octet-stream, and only if the encoding is<br>
either not present or is UTF-8 or ISO-8859-1.  Or whatever web servers<br>
do here.<br>
* Sniff the same both for video tags and top-level browsing contexts,<br>
so "open video in new tab" doesn't mysteriously fail on some setups.<br>
</blockquote>
<br>
I could probably live with those, actually.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
* If a file in a top-level browsing context is sniffed as video but<br>
then some kind of error is returned before the video plays the first<br>
frame, fall back to allowing the user to download it, or whatever the<br>
usual action would be if no sniffing had occurred.<br>
</blockquote>
<br>
This might be pretty difficult to implement, since the video decoder might consume arbitrary amounts of data before saying that there was an error.<br>
</blockquote>
<br>
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.<br>
<br>
--<br>
Philip Jägenstedt<br>
Core Developer<br>
Opera Software<br>
</blockquote>
<br>
David Singer<br>
Multimedia and Software Standards, Apple Inc.<br>
<br>
</blockquote>
<br>
<br>
-- <br>
Philip Jägenstedt<br>
Core Developer<br>
Opera Software<br>
</div></div></blockquote></div><br></div></div>