[Bug 13995] Don't check Content-Type for <track>


--- Comment #14 from Ian 'Hixie' Hickson <ian@hixie.ch> 2011-09-19 22:52:14 UTC ---
Ah, well, if you're saying you're not going to implement it then naturally I'll
update the spec accordingly.

Basically this means changing this paragraph:

"The tasks queued by the fetching algorithm on the networking task source to
process the data as it is being fetched must examine the resource's Content
Type metadata, once it is available, if it ever is. If no Content Type metadata
is ever available, or if the type is not recognised as a text track format,
then the resource's format must be assumed to be unsupported (this causes the
load to fail, as described below). If a type is obtained, and represents a
supported text track format, then the resource's data must be passed to the
appropriate parser (e.g. the WebVTT parser if the Content Type metadata is
text/vtt) as it is received, with the text track list of cues being used for
that parser's output."

...to something that instead of checking the Content-Type header recognises the
file format based on signatures, and add a note mentioning that this is an
intentional violation of the HTTP spec motivated by compatibility with

What's the signature for TTML?

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, 19 September 2011 22:52:17 UTC