Re: FormData and BlobBuilder - duplication of functionality?

On Wed, Apr 14, 2010 at 12:04 PM, Michael Nordman <michaeln@google.com> wrote:
> On Tue, Apr 13, 2010 at 9:01 PM, Jonas Sicking <jonas@sicking.cc> wrote:
>>
>> On Tue, Apr 13, 2010 at 7:35 PM, Michael Nordman <michaeln@google.com>
>> wrote:
>> > Good question. Let me ask you one. What value should you use for the
>> > content-type header? That value needs to contain the boundary string.
>> > You
>> > need to know that to xhr.send the data in a way that looks like a form
>> > submission. Just sending the blob will be "off by one" and the server
>> > side
>> > won't understand it.
>>
>> There seems to be general agreement (based on various discussions here
>> and on whatwg) that the .type property should be moved to the Blob
>> interface. So Blobs will have a content-type. So this problem should
>> be taken care of.
>>
>> / Jonas
>
> Yes indeed!
> So are we saying that FormData.toBlob() produces a blob representing the
> encoded
> results and having a .type property of the form...
> multipart/form-data; boundary=xxxxxxx

In the words of Samuel L Jackson: Correctamondo

;)

> [Constructor] interface FormData { Blob toBlob (); void append(DOMString
> name, Blob value); void append(DOMString name, DOMString value); };
> Also it looks like BlobBuilder (in the draft dimich linked to) is lacking a
> means for the caller to set the type attribute of the blob being built.
> A couple ways that could be provided...
> [Constructor] interface BlobBuilder { attribute DOMString endings;
> attribute DOMString type; // option a
> Blob getBlob (in DOMString type); // option b void append (in DOMString
> text) raises (FileException); void append (in Blob data); };

I don't feel strongly, but "option b" looks cleaner to me. Might want
to make the argument optional though, and default to the empty string.

/ Jonas

Received on Wednesday, 14 April 2010 21:20:30 UTC