- From: Jonas Sicking <jonas@sicking.cc>
- Date: Wed, 31 Aug 2011 10:57:29 -0700
- To: Glenn Maynard <glenn@zewt.org>
- Cc: Charles Pritchard <chuck@jumis.com>, public-webapps@w3.org
On Wed, Aug 31, 2011 at 10:19 AM, Glenn Maynard <glenn@zewt.org> 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.)
File attachments aren't submitted as part of
application/x-www-form-urlencoded encoding during form submission, so
I don't see why we should here. For multipart/form-data I think we
should always return a Blob which means that we wouldn't need to
actually read any contained blobs during encoding.
/ Jonas
Received on Wednesday, 31 August 2011 17:58:26 UTC