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

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

--- Comment #13 from Philip Jägenstedt <philipj@opera.com> 2011-09-16 12:11:33 UTC ---
(In reply to comment #12)

> "Any HTTP/1.1 message containing an entity-body SHOULD include a Content-Type
> header field defining the media type of that body. If and only if the media
> type is not given by a Content-Type field, the recipient MAY attempt to guess
> the media type via inspection of its content and/or the name extension(s) of
> the URI used to identify the resource. If the media type remains unknown, the
> recipient SHOULD treat it as type "application/octet-stream"."
> 
> But also note:
> 
> <http://trac.tools.ietf.org/wg/httpbis/trac/ticket/155>

Great, this is option 3.

> > As with <video>, I see 3 options here:
> > 
> > 1. Always obey Content-Type
> > 
> > 2. Always ignore Content-Type
> > 
> > 3. Add sniffing for WebVTT to
> > http://tools.ietf.org/html/draft-ietf-websec-mime-sniff-03 and use the sniffed
> > type, not the official content type. If spec'd as I imagine it, this would
> > allow serving WebVTT as text/plain, but serving it as application/ttml+xml
> > would fail.
> > 
> > (1) is unacceptable, (2) is what we've implemented, but (3) could be tolerable
> > if <video> were also made consistent with that.
> 
> I don't think (1) is unacceptable.

Will not implement, it is an unnecessary hoop for authors to jump through and
not actually necessary to support multiple text formats.

-- 
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 Friday, 16 September 2011 12:11:37 UTC