[Bug 11984] Simplify <video> for implementors and authors by ignoring the Content-Type HTTP header

http://www.w3.org/Bugs/Public/show_bug.cgi?id=11984

--- Comment #7 from Philip Jägenstedt <philipj@opera.com> 2011-02-14 21:45:27 UTC ---
(In reply to comment #6)
> Microsoft's position: IE9 RC strictly obeys the Content-Type returned to media
> elements. We believe this behaviour matches the latest Firefox 4 Beta. Based on
> feedback from developers and also following the "state of implementations"
> thread highlighted by Simon above, we changed the implementation of media
> elements between IE9 Beta and IE9 RC. While it required extra work in our
> browser engine to respect the Content-Type in this way, it turned out that this
> was less work than supporting a robust future-proof content-sniffing approach.
> Consequently we disagree that this change simplifies things for implementers
> and we request that the change be reverted. 
>
> Currently, we do not support media playback for content with the
> application/octet-stream content type. The working group should consider
> application/octet-stream support as a separate issue.

Uh, just when all browser vendors seemed to be OK with ditching Content-Type...

What about file:, ftp: and other protocols that don't have any equivalent of
Content-Type? What about when Content-Type is missing from a HTTP respsonse?

By reverting this change we'd be bringing back application/octet-stream which
you don't support. Wouldn't it be better to agree on something and change the
spec to that than to bring back something which doesn't match any browser and
never will?

-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Monday, 14 February 2011 21:45:30 UTC