18523 2012-08-10 14:57:39 +0000 Spec is unclear about the restriction on LWS in the attribute/value in the ABNF for media-type 2012-10-15 18:01:57 +0000 1 1 1 Unclassified WebAppsWG File API unspecified All All RESOLVED FIXED P2 normal --- 1 saurabhanandiit arun Ms2ger public-webapps public-webapps-bugzilla oldest_to_newest 72037 0 saurabhanandiit 2012-08-10 14:57:39 +0000 http://tools.ietf.org/html/rfc2616#section-3.7 says that "Linear white space (LWS) MUST NOT be used between the type and subtype, nor between an attribute and its value" whereas http://tools.ietf.org/html/rfc2616#section-3.6 says "parameter = attribute "=" value". NOTE : The white space between the word attribute and the equal to sign and similarly, equal to sign and the word value. In the Example section of http://dev.w3.org/2006/webapi/FileAPI/#constructorParams an instance is given of the call : var b = new Blob(["foobarbazetcetc", "birdiebirdieboo"], {type: "text/plain;charset=UTF-8"}); So, I assume |charset = UTF-8| should throw an error |charset=UTF-8| should not. Only two cases are possible : Either the example is wrong or the algorithm isn't clear enough. Expectation : Either a more clear language used in the IETF specification to explain the ABNF for media-type. 72062 1 arun 2012-08-10 20:43:22 +0000 I think this bug isn't one with the File API spec, but should be filed on RFC 2616. I defer to RFC 2616, and would prefer not to recreate rules already covered in RFC 2616. 76319 2 arun 2012-10-15 18:01:57 +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.