[whatwg] <video> application/octet-stream

On Thu, Jul 22, 2010 at 2:07 AM, Chris Double <chris.double at double.co.nz>wrote:

> When content sniffing are we ignoring the mime type served by the
> server and always sniffing? If so then incorrectly configured servers
> can result in more downloaded data due to having to read the data
> looking for a valid video. For example:
>
> <video>
>  <source src='foo.ogg'>
>  <source src='foo.mkv'>
> </video>
>
> If the web browser doesn't support Ogg but does support matroska, and
> the server sends the video/ogg content type,  the browser can stop and
> go to the next source after downloading very little data.
>
> If the web browser is expected to ignore the mime type and content
> sniff it must see if 'foo.ogg' is a matroska file. According to the
> matroska spec arbitary ASCII data can be placed before the EBML
> identifier. This means reading a possible large amount of data (even
> the entire file) before being able to say that it's not a matroska
> file.
>
> That type of scenario is what I was getting at about how much of the
> file should be read before giving up.
>

While that's true, in practice binary data will appear quite early in the
file, and we could even tighten up WebM to restrict the amount of ASCII data
that appears before the EBML identifier (perhaps to zero).

Also, in your example the author could have provided type="" attributes on
the <source> elements to control what gets downloaded. I assume that no-one
is proposing we ignore those.

While I don't like sniffing, apparently Safari and Chrome have already raced
straight to the bottom of the poisoned well here, so I don't think we really
have a choice.

Rob
-- 
"Now the Bereans were of more noble character than the Thessalonians, for
they received the message with great eagerness and examined the Scriptures
every day to see if what Paul said was true." [Acts 17:11]
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.whatwg.org/pipermail/whatwg-whatwg.org/attachments/20100722/a23030ff/attachment.htm>

Received on Wednesday, 21 July 2010 17:22:34 UTC