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