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

[And Clover]

On 09/07/2010 09:29 PM, Aryeh Gregor wrote:

> I'm not a fan of sniffing, but I'm also not a fan of blindly believing
> clearly wrong MIME types

Who decides what is "clearly wrong"? Perhaps I *meant* to serve a 
non-video file with something that looks a fingerprint from a video 
format at the top. In fact, given that HTML5 does not endorse or limit 
implementation to a particular video format, there could be any number 
of video formats whose header-words I have to avoid using in the first N 
bytes of my file.

If I were serving an image/png with no PNG header, you could say it was 
clearly wrong. But there's no way you can say any sequence of bytes is 
"clearly not application/octet-stream" or some other anything-goes type.

> I'm not yet sure what the correct tradeoff is here, but I'm pretty sure it's
> not "no sniffing at all under any conditions".

I suggest:

1. Resources with no Content-Type continue to be fair game.

2. By far the most prevalent "maybe wrong" Content-Type that is widely 
deployed is text/plain, due to inappropriate web server defaults (both 
IIS and Apache<2.3). Allow sniffing of text/plain resources, but provide 
an override for server operators to say "I mean it, this is really 
text/plain". ie. standardise X-Content-Type-Options or something like it.

3. Sniffing should otherwise not occur in any context.

It is unfortunate that sniffing will continue to be needed for the 
text/plain case for a very long time yet. But we should be aiming to 
mitigate and deprecate this historical error, rather than make the 
problem an order of magnitude worse by requiring potentially-limitless 
new sniffing cases.

> it's unreliable in the same way across all browsers.

It's already different in different browsers, even with the small number 
of filetypes we currently have. As previously commented, undistinctive 
fingerprints, starting mid-stream and other oddities like ID3 tags makes 
sniffing for media filetypes even more troublesome than it is for other 
types.

In any case, any sniffing solution will always be inconsistent as 
different browsers, OSes, installed codecs and options expose different 
media filetypes to the net.

Never mind just browsers, or even browsers that simply pass the resource 
to their underlying media frameworks for sniffing: there are far more 
already-deployed media players with HTTP capability than there are 
browsers with video/audio support. There is no chance we will ever be 
able to standardise the implementation of sniffing amongst this wide 
range of agents!

So there will always be non-compliant UAs. In the face of this, we might 
as well standardise the 'good' solution - minimal sniffing - and hope to 
drag a few modern browsers along with that, instead of mandating an 
unreliable sniffing approach that *still* isn't implemented universally.

> This is particularly essential for security -- undocumented
> sniffing behavior has caused more than one vulnerability in the past.

Yes. Undocumented sniffing behaviour has caused many vulnerabilities, as 
even well-known sniffing behaviour continues to do (see the current 
publicised difficulties with CSS-inclusion attacks). Lack of sniffing 
behaviour, however, has never caused a vulnerability. It fails safe.

-- 
And Clover
mailto:and at doxdesk.com
http://www.doxdesk.com/