On Tue, Apr 13, 2010 at 9:01 PM, Jonas Sicking <[email protected]> wrote:
> On Tue, Apr 13, 2010 at 7:35 PM, Michael Nordman <[email protected]> > 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 [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); };
