Re: File API: Blob.type

On Mar 6, 2013, at 7:42 PM, Glenn Maynard wrote: 

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. 

In fact, the intent is that the value of Blob.type is reflected in the Content-Type, and that setting Blob.type means that when fetching that Blob as a blob: you'll get the value of Blob.type in the Content-Type header. This model *did* allow for charset params -- it always has (perhaps not advertised, but it always has). 

At some point there was a draft that specified *strict* parsing for compliance with RFC2046, including tokenization ("/") and eliminating non-ASCII cruft. But we scrapped that because bugs in all major browser projects showed that this spec. text was callously ignored. And I didn't want to spec. fiction, so we went with the current model for Blob.type, which is, as Anne points out, pretty lax. 

>>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. 

I'm in favor of introducing stricter rules for Blob.type, and I'm also in favor of allowing charset params; Glenn's example of 'if(blob.type == "text/plain")' will break, but I don't think we should be encouraging strict equality comparisons on blob.type (and in fact, should *discourage* it as a practice). 

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. 

Glenn: I think that introducing a separate interface for other parameters actually takes away from the elegance of a simple Blob.type. The RFC doesn't separate them, and I'm not sure we should either. My reading of the RFC is that parameters *are an intrinsic part of* the MIME type. 

-- A* 

----- Original Message -----

> 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