On Fri, Mar 8, 2013 at 3:43 AM, Anne van Kesteren <ann...@annevk.nl> wrote:
> On Thu, Mar 7, 2013 at 6:35 PM, Arun Ranganathan > <aranganat...@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