18521 2012-08-10 10:14:34 +0000 Spec is unclear about lower-casing content types 2012-10-15 19:20:13 +0000 1 1 1 Unclassified WebAppsWG File API unspecified All All RESOLVED FIXED needs test P2 normal --- 1 Ms2ger arun julian.reschke odinho pavel.zubkou public-webapps saurabhanandiit public-webapps-bugzilla oldest_to_newest 72025 0 Ms2ger 2012-08-10 10:14:34 +0000 It is unclear what the type of new Blob([], { type: "TEXT/HTML" }) or new Blob().slice(0, 0, "TEXT/HTML"); should be ('text/html' or 'TEXT/HTML'). (Firefox has 'TEXT/HTML' twice; Chrome has 'text/html' for the former and 'TEXT/HTML' for the latter.) 72028 1 odinho 2012-08-10 11:05:31 +0000 Opera also has TEXT/HTML twice. 72061 2 arun 2012-08-10 20:39:30 +0000 I think it might be useful to spec. this to be lower case. 73362 3 arun 2012-09-06 20:12:24 +0000 In the spec., I defer to RFC2616, asking the parser to parse it in accordance with the definition of type and subtype tokens. RFC2616 says: The type, subtype, and parameter attribute names are case-insensitive. Parameter values might or might not be case-sensitive, depending on the semantics of the parameter name. Thus, TEXT/HTML is equivalent to text/html. This isn't a bug, but an implementation quirk. I don't think we need further spec. guidance on this issue. In fact, I think it places an emphasis on authors to coin the type string with some diligence. Authors get back what they ask for. Marking invalid. 73363 4 Ms2ger 2012-09-06 20:18:32 +0000 Step 5.2 of the Blob constructor algorithm is > Convert every character in s to lower case. There's something similar for slice(). 73365 5 arun 2012-09-06 20:30:33 +0000 This is a good catch. I think this should be removed. Thoughts? 73373 6 arun 2012-09-06 22:13:31 +0000 Like in Bug 18529, I am wondering whether we should forgo parsing for validity altogether. The prevailing school of thought is that browsers should just treat "type" as an opaque string. 76318 7 arun 2012-10-15 18:01:15 +0000 We've decided to treat type as an opaque string. Implementations don't throw; browser developers are reluctant to throw, and thus validation against the RFC is not useful.