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: Fri, 8 Mar 2013 17:36:14 -0600
Message-ID: <CABirCh9DYRBD1W67ECvK2We23c2faMXhTmyR7ypTjrcHjhd0+w@mail.gmail.com>
To: Anne van Kesteren <annevk@annevk.nl>
Cc: Arun Ranganathan <aranganathan@mozilla.com>, WebApps WG <public-webapps@w3.org>, Alexey Proskuryakov <ap@webkit.org>, Jonas Sicking <jonas@sicking.cc>
On Fri, Mar 8, 2013 at 3:43 AM, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Thu, Mar 7, 2013 at 6:35 PM, Arun Ranganathan
> <aranganathan@mozilla.com> 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 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:58 GMT