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.
Another way to deal with that would be to expose a FormData.boundary attribute. In my made up use case, callers would have to store the boundary out of band from the blob, and use it to make a properly formed content-type header value when xhr.send'ing the blob. Another reason isn't so much a "need"... but to make the programming interface symmetrical and hopefully easier to understand and use. On Tue, Apr 13, 2010 at 6:03 PM, Jonas Sicking <[email protected]> wrote: > On Tue, Apr 13, 2010 at 5:53 PM, Michael Nordman <[email protected]> > wrote: > > > > > > On Tue, Apr 13, 2010 at 5:39 PM, Jonas Sicking <[email protected]> wrote: > >> > >> On Tue, Apr 13, 2010 at 5:34 PM, Michael Nordman <[email protected]> > >> wrote: > >> > Hmmm... maybe FormData could have a toBlob() method, and an inverse > >> > means of > >> > initializing a FormData object with a properly encoded Blob. > >> > >> What's the use case? ;) > > > > Persisting FormData and reconstituting it at a later time. For example > when > > offline then back online. > > Why would you need to recode into a FormData object though? You can > submit a Blob using XHR the same way you can submit a FormData. > / Jonas >
