Re: File API: Blob.type

On Fri, Mar 8, 2013 at 3:43 AM, Anne van Kesteren <> wrote:

> On Thu, Mar 7, 2013 at 6:35 PM, Arun Ranganathan
> <> wrote:
> > But I'm not sure about why we'd choose ByteString in lieu of being strict
> > with what characters are allowed within DOMString.  Anne, can you shed
> some
> > light on this?  And of course we should eliminate CR + LF as a
> possibility
> > at constructor invocation time, possibly by throwing.
> MIME/HTTP consists of byte sequences, not code points. ByteString is a
> basic JavaScript string with certain restrictions on it to match the
> byte sequence semantics, while still behaving like a string.

MIME types are definitely strings of codepoints.  They're just strings.  We
wouldn't make <script type> or <style type> a ByteString.

And again, ByteString doesn't have anything to do with preventing CR/LF
from entering Blob.type.  You can still put CR/LF in ByteString, it does
nothing to solve the problem raised here.

ByteString is just a hack to deal with the unpleasant legacy of XHR not
encoding and decoding header text.  Don't leak that mess into Blob.  All
that's needed is the simple check I mentioned earlier (and similar
filtering in other places @type can be sourced from, if there are any other
places this could happen).

Glenn Maynard

Received on Friday, 8 March 2013 23:36:45 UTC