Bug 88696 - FileAPI: type should be converted to be lower case in Blob constructor.
Summary: FileAPI: type should be converted to be lower case in Blob constructor.
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebCore Misc. (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Li Yin
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2012-06-08 18:29 PDT by Li Yin
Modified: 2012-06-13 05:41 PDT (History)
7 users (show)

See Also:


Attachments
Patch (4.68 KB, patch)
2012-06-08 18:46 PDT, Li Yin
no flags Details | Formatted Diff | Diff
Patch (4.91 KB, patch)
2012-06-12 22:01 PDT, Li Yin
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Li Yin 2012-06-08 18:29:16 PDT
From Spec: http://dev.w3.org/2006/webapi/FileAPI/#dfn-BlobPropertyBag

If the optional BlobPropertyBag dictionary is used to invoke the constructor and has a type member, then user agents MUST run the following substeps:

...

Convert every character in s to lower case.
Comment 1 Li Yin 2012-06-08 18:46:22 PDT
Created attachment 146678 [details]
Patch
Comment 2 Kentaro Hara 2012-06-08 19:14:31 PDT
Comment on attachment 146678 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=146678&action=review

> LayoutTests/ChangeLog:9
> +        Spec: http://dev.w3.org/2006/webapi/FileAPI/#dfn-BlobPropertyBag
> +        Add sub-test to track changing upper case into lower case of type in Blob constructor.

I think the spec description might be ambiguous, and I am not sure if we should make this change. IMHO, "Create a Blob with type='CamelCase', then blob.type will return 'camelcase'" sounds strange compared to other constructor behaviors.

The spec says as follows:

    6. If the optional BlobPropertyBag dictionary is used to invoke the constructor and has a type member, then user agents MUST run the following substeps:

        ...
        2. Convert every character in s to lower case.
        3. Parse s as an RFC2616 media-type, tokenizing it according to the ABNF for media-type, ...

    7. ... otherwise, set this Blob object's type to s.

If we read the spec naively, "CamelCase" should be converted to "camelcase", and then "camelcase" should be set to type. However, ---although this is just my personal opinion---, the spec might be intending the following interpretation:

    6. If the optional BlobPropertyBag dictionary is used to invoke the constructor and has a type member, then user agents MUST run the following substeps:

        ...
        2. Convert every character in s to lower case.
        3. Parse ***the lower-cased string*** as an RFC2616 media-type, tokenizing it according to the ABNF for media-type, ...

    7. ... otherwise, set this Blob object's type to s.

In this case, the lower-case conversion is just for obtaining the media-type, and s is still "CamelCase". IMHO, this behavior sounds more reasonable to me.

(Correct me if I'm wrong. If you would have the same idea, you can file a spec bug to clarify the intention of the spec.)
Comment 3 Li Yin 2012-06-08 19:54:52 PDT
(In reply to comment #2)
> (From update of attachment 146678 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=146678&action=review
> 
> > LayoutTests/ChangeLog:9
> > +        Spec: http://dev.w3.org/2006/webapi/FileAPI/#dfn-BlobPropertyBag
> > +        Add sub-test to track changing upper case into lower case of type in Blob constructor.
> 
> I think the spec description might be ambiguous, and I am not sure if we should make this change. IMHO, "Create a Blob with type='CamelCase', then blob.type will return 'camelcase'" sounds strange compared to other constructor behaviors.

Maybe I think the spec means the type should not be case-sensitive.
That is to say, we use {type: "CamelCase"} or {type: "camelcase"} will get the same result. (This is just my understanding)

Thanks for your comments.
Comment 4 Kentaro Hara 2012-06-08 20:04:53 PDT
(In reply to comment #3)
> Maybe I think the spec means the type should not be case-sensitive.
> That is to say, we use {type: "CamelCase"} or {type: "camelcase"} will get the same result. (This is just my understanding)

I agree that the type should be case-unsensitive, but maybe the type attribute should keep the original value that JS specified. Specifically, my (personal) expectation is:

new Blob([], {type: "text/html"});   // Recognized as "text/html"
new Blob([], {type: "Text/Html"});   // Recognized as "text/html"
new Blob([], {type: "text/html"}).type;   // "text/html"
new Blob([], {type: "Text/Html"}).type;   // "Text/Html"
new Blob([], {type: "text/html; charset=UTF-8"}).type;   // "text/html; charset=UTF-8"

It seems a bit strange to me if the result is "text/html; charset=utf-8".(http://www.w3.org/TR/FileAPI/#enctype)
Comment 5 Li Yin 2012-06-08 20:21:24 PDT
(In reply to comment #4)
> (In reply to comment #3)
> > Maybe I think the spec means the type should not be case-sensitive.
> > That is to say, we use {type: "CamelCase"} or {type: "camelcase"} will get the same result. (This is just my understanding)
> 
> I agree that the type should be case-unsensitive, but maybe the type attribute should keep the original value that JS specified. Specifically, my (personal) expectation is:
> 
> new Blob([], {type: "text/html"});   // Recognized as "text/html"
> new Blob([], {type: "Text/Html"});   // Recognized as "text/html"
> new Blob([], {type: "text/html"}).type;   // "text/html"
> new Blob([], {type: "Text/Html"}).type;   // "Text/Html"
> new Blob([], {type: "text/html; charset=UTF-8"}).type;   // "text/html; charset=UTF-8"
> 
> It seems a bit strange to me if the result is "text/html; charset=utf-8".(http://www.w3.org/TR/FileAPI/#enctype)

Okay, the spec seems unclear for this behavior.
Let me file a bug in w3c bugzilla.
Comment 6 Li Yin 2012-06-08 20:44:03 PDT
I filed a bug in W3C bugzilla.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=17449
Comment 7 Li Yin 2012-06-12 21:34:39 PDT
From Spec: http://dev.w3.org/2006/webapi/FileAPI/#attributes-blob
The ASCII-encoded string in lower case representing the media type of the Blob.

It explicitly specified the type should be lower case.
That is to say, it is a webkit bug, we still need to fix it.
Comment 8 Kentaro Hara 2012-06-12 21:37:05 PDT
(In reply to comment #7)
> From Spec: http://dev.w3.org/2006/webapi/FileAPI/#attributes-blob
> The ASCII-encoded string in lower case representing the media type of the Blob.
> 
> It explicitly specified the type should be lower case.
> That is to say, it is a webkit bug, we still need to fix it.

Thank you very much for the clarification. Then the latest patch looks OK to me.

kinuko-san: Would you take a look?
Comment 9 Li Yin 2012-06-12 21:41:28 PDT
I need to redesign the test.
Please wait for my update.
Thanks.
Comment 10 Li Yin 2012-06-12 22:01:43 PDT
Created attachment 147225 [details]
Patch
Comment 11 Li Yin 2012-06-12 22:09:08 PDT
Update the test case, use the correct media-type format.
Would you please have a check again?
Thanks in advance.
Comment 12 Kentaro Hara 2012-06-12 22:13:35 PDT
LGTM.

kinuko-san: review?
Comment 13 Kinuko Yasuda 2012-06-12 22:31:06 PDT
Comment on attachment 147225 [details]
Patch

LGTM too. Thanks for fixing!
Comment 14 WebKit Review Bot 2012-06-13 05:41:40 PDT
Comment on attachment 147225 [details]
Patch

Clearing flags on attachment: 147225

Committed r120191: <http://trac.webkit.org/changeset/120191>
Comment 15 WebKit Review Bot 2012-06-13 05:41:45 PDT
All reviewed patches have been landed.  Closing bug.