[whatwg] <video> application/octet-stream

> On Wed, Jul 21, 2010 at 10:24 AM, Chris Double
> <chris.double at double.co.nz> wrote:
>> On Thu, Jul 22, 2010 at 2:15 AM, Mike Shaver <mike.shaver at gmail.com> wrote:
>>> ...I would probably suggest that the
>>> developers of said browser implement basic Ogg support (enough to say
>>> "this is Ogg, so we don't support it"), and go back to solving more
>>> pressing problems!
>> 
>> Or the developers of said browser could obey the mime type that the
>> server sent,
> 


Yes please!

While the mime type discussion has been specific to video so far, as an author I'd like to take a step back and look at it in a more general way. First off, I'd expect handling of mime types to be consistent across the board of all mime types, and more specifically, I'd expect browsers to respect them. Wether it's text, image or video.
For example, if I serve a document, containing text that looks like an html document, as text/plain, I'd expect the browser to serve it as text/plain. 

If my web server can't handle mapping from a specific file to mime type, I can always deal with that through server side scripting, and instead of providing direct access to "video1.ogg" I'd go through "video.php?1" and set the headers myself. If I screw up, either through server side scripting or due to not configuring the web server correctly, or by choosing a web server that does not provide the functionality I need, I do not see that as the fault of browser developers. However, I do find it annoying to have to add a header like "x-content-type-options: nosniff" to force certain browsers to respect my choice of mime type.

As for the issue of container format, I see this as a different matter. Either you support the container format or not, and either way respect the mime type for it. Wether you support zero, one or more of the possible container payloads has nothing to do with respecting mime type or sniffing. The mime type lets you decide wether to accept or reject the container, and if you accept it you will of course have to find out what codec to use.

Also, the mime type/subtype can be followed by a parameter attribute=value list, which should make it possible to specify a codec thus even removing the need for a user agent to detect the format of the container contents. If no such parameter is present, fallback to ordinary format detection is of course necessary. And as far as I can tell, this seems to be allready specified by http://tools.ietf.org/html/rfc4281 in general and specifically for ogg in http://tools.ietf.org/html/rfc5334#section-10

Aside from that, I do not quite understand why this is discussed under the title "application/octet-stream". Looking at http://www.rfc-editor.org/rfc/rfc2046.txt, section 3.  Overview Of The Initial Top-Level Media Types, bullet 5:
"The subtype "octet-stream" is to be used in the case of uninterpreted binary data, in which case the simplest recommended action is to offer to write the information into a file for the user."

Johan

Received on Thursday, 22 July 2010 05:18:38 UTC