Bugzilla – Bug 16728
Last modified: 2012-05-07 06:46:54 UTC
"The ASCII-encoded string in lower case representing the media type of the Blob"
DOMStrings aren't ASCII-encoded. If type was set with the Blob() constructor, it isn't necessarily in lowercase, either.
Is the intent for it to be restricted to the ASCII subset, and/or converted to lowercase in the ctor?
I looked at RFC2046 and at the HTML5 specification, which
*sigh Sorry for Comment 2; I submitted too soon.
I looked at RFC2046 and at the HTML5 specification, which defines a valid MIME type string as matching RFC2616's media types section (3.7), to see if MIME type strings themselves are restricted to ASCII. They aren't as far as I can tell, and so we shouldn't have this requirement.
RFC 2616 section 3.7 says:
media-type = type "/" subtype *( ";" parameter )
type = token
subtype = token
Section 2.2 says:
token = 1*<any CHAR except CTLs or separators>
Section 2.2 says:
CHAR = <any US-ASCII character (octets 0 - 127)>
So MIME types are in fact restricted to ASCII. Furthermore, they're restricted to a subset of ASCII: "except CTLs or separators".
So my first reading was right, which is why the requirement was there. But it's true that DOMStrings aren't ASCII-encoded. We may as well ignore this, and do what we do for invalid MIME types on the platform in general. Otherwise maybe we'd have to specify that:
1. Implementations throw if type is set with "invalid" non-ASCII chars
2. Specify that implementations do case conversion, if necessary.
Don't know if we can really do those.
> do what we do for invalid MIME types on the platform in general.
It probably varies. At least some implementations, in some cases, byte-deflate and ASCII-lowercase.
We can do that in the Blob constructor and in Blob.slice (and anywhere else where Blobs are created with an author-specified MIME type).
Marking this fixed. http://dev.w3.org/2006/webapi/FileAPI/#dfn-Blob