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

On Tue, Jul 20, 2010 at 3:33 AM, Julian Reschke <julian.reschke@gmx.de>wrote:

> Can somebody explain the rational for treating application/octet-stream the
> same way as absent media type information?
>
> Note, <http://greenbytes.de/tech/webdav/rfc2046.html#rfc.section.4.5.1>:
>
>  The recommended action for an implementation that receives an
>> "application/octet-stream" entity is to simply offer to put the data in a
>> file, with any Content-Transfer-Encoding undone, or perhaps to use it as
>> input to a user-specified process.
>>
>
It makes sense to offer to save data into a file when you navigate to a URI
returning an application/octet-stream. But I don't think it makes sense to
do this for <video> loads.

Since application/octet-stream is a generic response, and there isn't
anything useful one could do with it in a <video> context as-is, I think it
makes sense to allow or even require sniffing of that type in that context
and reap the benefits of some small amount of compatibility with deployed
content.

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]