W3C home > Mailing lists > Public > public-webapps@w3.org > July to September 2011

Re: [XHR2] Blobs, names and FormData

From: Glenn Maynard <glenn@zewt.org>
Date: Wed, 31 Aug 2011 13:19:02 -0400
Message-ID: <CABirCh-Y2kUZ784kaTuOsee4NC-sVVuoa847-fx-GRQsQV+rfg@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Charles Pritchard <chuck@jumis.com>, public-webapps@w3.org
On Wed, Aug 31, 2011 at 12:48 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> > Simple case:
> > var callback = function(blob) { xhr.send(blob); };
> > formData.toBlob(callback, 'multipart/form-data');
> >
> > Several services require signed messages in the http header, the
> scripting
> > environment needs access to the blob data in order to sign the message
> body.
>
> Neither multipart/form-data nor application/x-www-form-urlencoded
> encoding is not slow, so there should be no need to make this an
> asynchronous callback.
>

Sorry if this doesn't make sense as I havn't been following this closely
enough, but if the form contains a file, this will cause the file to be read
from disk immediately, creating the encoded blob in memory, right?  If it
may trigger I/O, it should be async, regardless of how expensive the
operation performed on the resulting data might be.

(It may be possible for implementations to create a Blob class that
generates the encoded form-data on demand, as async reads happen later on.
But, even if that's possible for form-data, it won't necessarily be for
other possible types passed to toBlob, eg. x-www-form-urlencoded.)

-- 
Glenn Maynard
Received on Wednesday, 31 August 2011 17:19:39 GMT

This archive was generated by hypermail 2.3.1 : Tuesday, 26 March 2013 18:49:47 GMT