[whatwg] Error handling for MIME type parsing (canPlayType)

[Ian Hickson]

On Tue, 14 Jul 2009, Philip Jägenstedt wrote:
>
> While implementing canPlayType I've found that Firefox/Safari/Chrome (and now
> Opera) all have different error handling in parsing the MIME types. RFC
> 2045[1] gives the BNF form, but it appears that no browser gives much weight
> to this.
> 
> Sample of quirks:
> 
> (Ignore "no" vs "" here, it's not relevant)
> 
> Firefox:
> 
> AUDIO/X-WAV: "no"
> audio/x-wav codecs: "maybe"
> audio/x-wav; codecs=: "probably"
> audio/x-wav; codecs=,: "no"
> 
> Safari:
> 
> AUDIO/X-WAV: "no"
> audio/x-wav codecs: "no"
> audio/x-wav; codecs=: "probably"
> audio/x-wav; codecs=,: "maybe"
> 
> Opera internal:
> 
> AUDIO/X-WAV: ""
> audio/x-wav codecs: ""
> audio/x-wav; codecs=: "maybe"
> audio/x-wav; codecs=,: "maybe"
> 
> Chrome ignores codecs, so I can't get meaningful results.
> 
> I believe the correct answers are:
> 
> AUDIO/X-WAV: same as for audio/x-wav (by RFC 2045, but we could ignore it
> because it looks ugly)
> audio/x-wav codecs: the same as audio/x-unknown-type (i.e. "no" for Firefox)
> audio/x-wav; codecs=: same as audio/x-wav (unless we want this to mean "no
> codecs", in which case "no" would be more appropriate)
> audio/x-wav; codecs=,: same as audio/x-wav (i.e. ignore broken codecs
> parameter)
> 
> Has there been any work done on defining error handling for Content-Type 
> parsing or the like? It wouldn't be fun to get cross-browser bugs as 
> soon as someone forgets a semicolon...

On Wed, 15 Jul 2009, Robert O'Callahan wrote:
> 
> In Firefox I just reused our existing MIME type parser. I'm not sure how
> tightly that parser is constrained by Web compatibility quirks issues.
> 
> audio/x-wav codecs: the same as audio/x-unknown-type (i.e. "no" for Firefox)
> 
> 
> Yes, that seems like a bug.
> 
> audio/x-wav; codecs=: same as audio/x-wav (unless we want this to mean "no
> > codecs", in which case "no" would be more appropriate)
> 
> 
> I interpret this as "no codecs". In that case, "probably" is correct, since
> we support every codec in the list.
> 
> audio/x-wav; codecs=,: same as audio/x-wav (i.e. ignore broken codecs
> > parameter)
> 
> 
> I interpret this as two codecs, both whose name is the empty string. We
> don't support that codec.
> 
> Has there been any work done on defining error handling for Content-Type
> > parsing or the like?
> 
> 
> That's a very good question, but I don't know the answer.

HTML5 has some rules for parsing Content-Type that are designed for 
particular cases where it is constrained, but I don't think this is such a 
case. I would recommend asking the relevant working group (HTTP?) for 
guidance on how to parse these headers when they have bogus values.

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'