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


--- Comment #12 from Julian Reschke <julian.reschke@gmx.de> 2011-09-16 09:06:35 UTC ---
(In reply to comment #11)
> I can't find any MUST requirements at all in
> http://tools.ietf.org/html/rfc2616#section-14.17 or related sections, how would
> this be a violation?

Whether or not there is a MUST doesn't tell you anything about whether it's a
requirement or not. You seem to be confused about when or not BCP14 keywords
need to be used; see RFC 2119 for details. Note that there are entire RFCs
without any BCP 14 keywords; that doesn't affect their "normativeness" at all.

That being said,
<http://greenbytes.de/tech/webdav/rfc2616.html#rfc.section.7.2.1> says:

"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:


> 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.

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 09:06:45 UTC