[whatwg] Video with MIME type application/octet-stream
and-py at doxdesk.com
Wed Sep 8 12:13:25 PDT 2010
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".
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
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.
mailto:and at doxdesk.com
More information about the whatwg