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

Re: [XHR2] Blobs, names and FormData

From: Charles Pritchard <chuck@jumis.com>
Date: Wed, 31 Aug 2011 10:29:35 -0700
Message-ID: <4E5E6F7F.5040003@jumis.com>
To: Glenn Maynard <glenn@zewt.org>
CC: Jonas Sicking <jonas@sicking.cc>, public-webapps@w3.org
On 8/31/2011 10:19 AM, Glenn Maynard wrote:
> 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.)

That sounds correct. Yes, a very large blob file, x-www-form-urlencoded 
would have to be
read through to determine the output blob size. I agree, that 
specialized Blob classes could cut-down/delay
memory copies.
Received on Wednesday, 31 August 2011 17:30:11 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:13:23 UTC