Re: video/@src vs application/octet-stream

On Mon, Jul 19, 2010 at 11:20 AM, Julian Reschke <julian.reschke@gmx.de> wrote:
> On 19.07.2010 20:09, Maciej Stachowiak wrote:
>> For Safari/WebKit, we wanted to make it possible for the<video>  element
>> to play content that was previously embedded via the QuickTime plugin or
>> other plugins we support. Unfortunately, a fair proportion of such content
>> is being served with the wrong MIME type, most typically
>> application/octet-stream but sometimes also text/plain. We thought it might
>> create too high a barrier, if authors had to reconfigure their Web servers
>> before they could switch from the QuickTime plugin to<video>.
>
> Thanks for the feedback.
>
> So, does this make Safari non-compliant? It appears so, as
> draft-abarth-mime-sniff doesn't mention sniffing for video, and the spec
> text about video/@src doesn't seem to make an exception.

>From http://tools.ietf.org/html/draft-abarth-mime-sniff-05#section-5:

[[
   User agents MAY support additional types if necessary, by implicitly
   adding to the above table.  However, user agents SHOULD NOT not use
   any other patterns for types already mentioned in the table above
   because this could then be used for privilege escalation (where,
   e.g., a server uses the above table to determine that content is not
   HTML and thus safe from cross-site scripting attacks, but then a user
   agent detects it as HTML anyway and allows script to execute).  In
   extending this table, user agents SHOULD NOT introduce any privilege
   escalation vulnerabilities.
]]

However, what matters is not a legalistic reading of the
specifications.  What matters is the market forces.  If you don't want
browsers to sniff video (or some future type for some future API), you
need to change the underlying incentive structure.

Adam

Received on Monday, 19 July 2010 18:30:28 UTC