[Bug 24673] Make all content type string checks case-sensitive

https://www.w3.org/Bugs/Public/show_bug.cgi?id=24673

David Dorwin <ddorwin@google.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |singer@apple.com

--- Comment #3 from David Dorwin <ddorwin@google.com> ---
FYI, WebKit's and Blink's implementation of canPlayType() is:
 * container is case-insensitive
 * codecs are case-sensitive "because MP4 values are case sensitive per
http://tools.ietf.org/html/rfc4281#page-7." (The reference should be updated to
http://tools.ietf.org/html/rfc6381#section-3.3.)

(In reply to Adrian Bateman [MSFT] from comment #2)
> I don't think we should make the content type comparisons case-sensitive. I
> wouldn't want to have to fail playback simply because someone mis-typed
> "Video/mp4" in their code.

If browsers are consistent from the beginning, it will fail in all of them and
they can detect and fix the problem immediately. Note that since (MP4) codecs
are case-sensitive, mis-typing "Avc1" would similarly cause the app to fail.
However, the RFC below is clear.

> RFC6838 defines that top-level type and subtype are case-insensitive and I
> think we should follow this.
> See http://tools.ietf.org/html/rfc6838#section-4.2
> 
> (In reply to David Dorwin from comment #1)
> > Regardless of the decision on the above suggestion, we should recommended
> > that applications use simple lower-case ASCII strings when possible. Even if
> > we can't force case-sensitive comparisons on implementations, this should be
> > the most interoperable option.
> 
> I am fine with suggesting a non-normative best practice to always use
> lower-case ASCII strings if possible.

On second thought, this would actually be inconsistent with RFC 4281/6381
(since http://www.mp4ra.org/codecs.html contains some capitalized codes).

Maybe we should just note, possibly non-normatively, that comparisons are based
on the respective definitions along with the comment that this means the type
and subtype is case-insensitive and codecs are (may be) case-sensitive.

-- 
You are receiving this mail because:
You are the QA Contact for the bug.

Received on Saturday, 22 February 2014 00:04:00 UTC