[whatwg] Error handling for MIME type parsing (canPlayType)
Ian Hickson
ian at hixie.ch
Tue Jul 28 17:40:37 PDT 2009
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. `._.-(,_..'--(,_..'`-.;.'
More information about the whatwg
mailing list