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 <jonas@sicking.cc> wrote:
> On Tue, Apr 13, 2010 at 5:53 PM, Michael Nordman <michaeln@google.com>
> wrote:
> >
> >
> > On Tue, Apr 13, 2010 at 5:39 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> >>
> >> On Tue, Apr 13, 2010 at 5:34 PM, Michael Nordman <michaeln@google.com>
> >> 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
>