[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 #1 from Simon Pieters <simonp@opera.com> 2011-02-05 00:18:13 UTC ---
Rationale 

The current state of implementations is a mess, as summarized by Ian Hickson
(http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-August/028291.html ): 
"Microsoft's position is, as far as I can tell, that there's no point looking
at the Content-Type header, [...]" 
"Safari does crazy things right now that we won't go into; [...]" 
"Chrome right now sniffs like IE, [...]" 
"Opera does what the spec suggests. [...]" 
"Mozilla respects the Content-Type religiously, [...]" 

The currently specified handling of Content-Type has concrete negative
side-effects for both implementors and authors, outlined in the following
sections. 

Rather than continuing to maintain this mess, we should jump directly to the
most sane of the likely outcomes, which is to always ignore Content-Type for
<video>. 


Issues for Implementors 

* Because application/octet-stream is special-cased in canPlayType, the same
code path cannot be used for canPlayType as for checking Content-Type and
<source type>. 
* In the resource fetch algorithm, if the resource is transferred using many
HTTP byte range requests, it's unclear if Content-Type should be checked on the
first request, or on every request. Either would be problematic: 
   - Checking it only once is inconsistent because on subsequent requests,
Content-Type may have changed, but this would be ignored. 
   - Checking it for every request could amount to very many times during the
playback of a long video. If the underlying media framework must be queried
each time, it could be time-consuming. Introducing caching to work around it
increases the risk of bugs. 
* In order to be compatible with what is sent in Content-Type, implementations
must support several synonymous MIME types. This is exposed via canPlayType,
where there was no legacy to consider originally, creating unnecessary room for
incompatibilities. For example, Firefox supports 4 different MIME types for
WAVE, Opera supports 3 and Chrome supports 2.
(http://wiki.whatwg.org/wiki/Video_type_parameters#Browser_Support ) 


Issues for Authors 

* Because of the way application/octet-stream is special-cased, the result of
canPlayType is subtly different from how Content-Type and <source type> are
treated, which is confusing. For example,
canPlayType("application/octet-stream") returns "", while
canPlayType("application/octet-stream;") returns "maybe". Yet, using either
value in Content-Type should cause the user agent to use sniffing to determine
the resource type and try decoding it. 
* Many servers are not configured to serve the correct Content-Type for audio
and video types: 
   - Authors who are not aware of the requirements on Content-Type will go
through time-consuming debugging before eventually learning how to configure
their server. 
   - Authors who cannot control what Content-Type HTTP header is sent by their
server will be unable to use <video> at all. 


Details 

* Remove all mention of application/octet-stream from the <video> section,
especially: 
   - The special-casing of application/octet-stream from the canPlayType
method. 
* Remove all mention of Content-Type from the <video> section, especially: 
   - The following case from the resource fetch algorithm: "If the media
resource is found to have Content-Type metadata that, when parsed as a MIME
type (including any codecs described by the codecs parameter, if the parameter
is defined for that type), represents a type that the user agent knows it
cannot render (even if the actual media data is in a supported format)" 


Impact 

Positive Effects 
* The behavior of <video> with respect to Content-Type is aligned with how e.g.
<img> already works. 
* No more time is spent maintaining an unstable situation on which it is very
unlikely implementations will converge. 
* Implementations of <video> are simplified. 
* The incentive for supporting many different equivalent MIME types in
canPlayType and <source type> is removed, as they come only from legacy
Content-Type issues. 
* Some legacy MIME types, such as audio/x-pn-wav, can likely be removed from
implementations of canPlayType. 
* Using <video> becomes simpler for authors. 


Negative Effects 

* Video will always play in a <video> context but may fail in a top-level
browsing content, depending on the Content-Type and what sniffing is used.
(This is already the situation for images.) 
* Content-Type as the definitive mechanism for type information in HTTP is
undermined even further. 


Conformance Classes Changes 

User Agents 


Risks 

* Failure to standardize sniffing of video types may result in poor
interoperability. This is already the case, as the spec currently requires
sniffing after checking Content-Type. However, the risk does increases somewhat
when more implementations switch to always sniffing. 

Note: Work on standardized sniffing for audio and video types has already begun
in Media Type Sniffing.
http://tools.ietf.org/html/draft-ietf-websec-mime-sniff-01


(Note: This bug is basically foolip's CP for ISSUE-145
(http://www.w3.org/html/wg/wiki/ChangeProposals/NoVideoContentType ). However,
I think his CP is not appropriate as a CP for ISSUE-145 since it makes a
substantive change while the original bug was about an editorial issue.
Therefore I think it is more appropriate for foolip's CP to be a separate bug,
hence this bug.)

-- 
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 Saturday, 5 February 2011 00:18:15 UTC