On Wed, Mar 6, 2013 at 8:29 AM, Anne van Kesteren <[email protected]> wrote:
> On Wed, Mar 6, 2013 at 2:21 PM, Glenn Maynard <[email protected]> wrote: > > 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. > > It's a Content-Type header value and should have those restrictions. > It's not a Content-Type header, it's a MIME type. That's part of a Content-Type header, but they're not the same thing. But String vs. ByteString has nothing to do with the restrictions applied to it. Making it a ByteString plus additional restrictions will make it do as > required. > That doesn't make sense. Blob.type isn't a string of bytes, it's a string of Unicode codepoints that happens to be restricted to the ASCII range. Applying WebKit's validity checks (with the addition of disallowing nonprintable characters) will make it have the restrictions you want; ByteString has nothing to do with this. On Wed, Mar 6, 2013 at 11:47 AM, Darin Fisher <[email protected]> wrote: > So the intent is to allow specifying attributes like "charset"? That > sounds useful. > I don't think so. This isn't very well-defined by RFC2046 (it seems vague about the relationship of parameters to MIME types), but I'm pretty sure Blob.type is meant to be only a MIME type, not a MIME type plus content-type parameters. Also, it would lead to a poor API: you could no longer simply say 'if(blob.type == "text/plain")'; you'd have to parse it out yourself (which I expect nobody is actually doing). Other parameters should have a separate interface, eg. blob.typeParameters.charset = "UTF-8", if we want that. -- Glenn Maynard
