Re: File API: Blob.type

On Wed, Mar 6, 2013 at 8:29 AM, Anne van Kesteren <annevk@annevk.nl> wrote:

> On Wed, Mar 6, 2013 at 2:21 PM, Glenn Maynard <glenn@zewt.org> 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 <darin@chromium.org> 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