Bug 18523 - Spec is unclear about the restriction on LWS in the attribute/value in the ABNF for media-type
Spec is unclear about the restriction on LWS in the attribute/value in the AB...
Status: RESOLVED FIXED
Product: WebAppsWG
Classification: Unclassified
Component: File API
unspecified
All All
: P2 normal
: ---
Assigned To: Arun
public-webapps-bugzilla
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-10 14:57 UTC by Saurabh Anand
Modified: 2012-10-15 18:01 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Saurabh Anand 2012-08-10 14:57:39 UTC
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.
Comment 1 Arun 2012-08-10 20:43:22 UTC
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.
Comment 2 Arun 2012-10-15 18:01:57 UTC
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.