Re: [XHR2] Blobs, names and FormData

On 8/31/2011 10:57 AM, Jonas Sicking wrote:
> 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.

A Blob is not necessarily a file attachment, it could simply be a large 
string.
x-www-form-urlencoded would not serialize the mime type nor file name.

Received on Wednesday, 31 August 2011 20:38:59 UTC