Warning:
This wiki has been archived and is now read-only.

ChangeProposals/NoVideoContentType

From HTML WG Wiki
Jump to: navigation, search

No <video> Content-Type

Written by Philip Jägenstedt.

Summary

Simplify <video> for implementors and authors by ignoring the Content-Type HTTP header, thereby removing the need to mention application/octet-stream at all.

Note: All proposed changes to <video> should also apply to <audio>.

Rationale

ISSUE-145 is about the mention of the codecs parameter for the application/octet-stream type.

The only reason that application/octet-stream is mentioned in the spec at all is because it tries to reach some kind of compromise on how to deal with the Content-Type HTTP header. The current state of implementations is a mess, as summarized by Ian Hickson:

  • "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. (source)

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.

References


Articles and documentation for <video> that mention Content-Type:


Stack Overflow questions where the root cause was an incorrect Content-Type:

Retrieved from "https://www.w3.org/html/wg/wiki/index.php?title=ChangeProposals/NoVideoContentType&oldid=8946"