Bug 18521 - Spec is unclear about lower-casing content types
Spec is unclear about lower-casing content types
Status: RESOLVED FIXED
Product: WebAppsWG
Classification: Unclassified
Component: File API
unspecified
All All
: P2 normal
: ---
Assigned To: Arun
public-webapps-bugzilla
needs test
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2012-08-10 10:14 UTC by Ms2ger
Modified: 2012-10-15 19:20 UTC (History)
5 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ms2ger 2012-08-10 10:14:34 UTC
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.)
Comment 1 Odin Hørthe Omdal 2012-08-10 11:05:31 UTC
Opera also has TEXT/HTML twice.
Comment 2 Arun 2012-08-10 20:39:30 UTC
I think it might be useful to spec. this to be lower case.
Comment 3 Arun 2012-09-06 20:12:24 UTC
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.
Comment 4 Ms2ger 2012-09-06 20:18:32 UTC
Step 5.2 of the Blob constructor algorithm is

> Convert every character in s to lower case.

There's something similar for slice().
Comment 5 Arun 2012-09-06 20:30:33 UTC
This is a good catch.  I think this should be removed.  Thoughts?
Comment 6 Arun 2012-09-06 22:13:31 UTC
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.
Comment 7 Arun 2012-10-15 18:01:15 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.