W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2013

Re: File API: Blob.type

From: Glenn Maynard <glenn@zewt.org>
Date: Wed, 6 Mar 2013 08:21:34 -0600
Message-ID: <CABirCh-6PadyhuwS5Mi2pbYw2XsMasfOpb0NAErrSCm4b-AKLg@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: WebApps WG <public-webapps@w3.org>, Alexey Proskuryakov <ap@webkit.org>, Arun Ranganathan <arun@mozilla.com>, Jonas Sicking <jonas@sicking.cc>
On Wed, Mar 6, 2013 at 3:22 AM, Anne van Kesteren <annevk@annevk.nl> wrote:

> Okay, so given https://bugs.webkit.org/show_bug.cgi?id=111380 I think
> we should put at least minimal restrictions on Blob's constructor
> concerning Blob.type. We made it "anything goes" because in theory
> with Content-Type anything goes. But of course that is false and we
> should have noticed that at the time. Content-Type's value cannot
> contain CRLF, Content-Type's value is also a byte sequence, not a code
> point sequence, and certainly not a code unit sequence.
> 1. I think we should change the type from DOMString to ByteString,
> just like XMLHttpRequest has it.

Blob.type is a MIME type, not a Content-Type header.  It's a string of
codepoints, not a series of bytes.  XHR is a protocol-level API, so maybe
it makes sense there, but it doesn't make sense for Blob.

WebKit already throws SyntaxError for codepoints outside the ASCII range,
eg. new Blob([], {type: "漢字"}).  This should just be extended to throw for
anything that isn't printable ASCII, which would include CR, LF, and other
control characters (especially nil).  In other words, anything not in the
Unicode range [U+0020,U+007E].

It doesn't look like WebKit's exception is in the spec.  I think this
should be added.

Also, WebKit lowercases the type parameter.  This doesn't seem to be in the
spec.  (http://dev.w3.org/2006/webapi/FileAPI/#dfn-type says "ASCII-encoded
string in lower case", but that's non-normative.)  I think it should be.

Glenn Maynard
Received on Wednesday, 6 March 2013 14:22:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:58 UTC