Re: [XHR2] Blobs, names and FormData

On 8/30/2011 7:11 PM, Jonas Sicking wrote:
> On Tue, Aug 30, 2011 at 5:59 PM, Charles Pritchard<chuck@jumis.com>  wrote:
>> On 8/30/11 5:52 PM, Jonas Sicking wrote:
>>> On Tue, Aug 30, 2011 at 3:26 PM, Charles Pritchard<chuck@jumis.com>
>>>   wrote:
>>>
>>>> On 8/24/2011 11:56 PM, Charles Pritchard wrote:
>>>>
>>>>> On 8/24/11 11:36 PM, Jonas Sicking wrote:
>>>>>
>>>>>> On Wed, Aug 24, 2011 at 12:57 PM, Charles Pritchard<chuck@jumis.com>
>>>>>>   wrote:
>>>>>>
>>>>>>>>> Prpoposed:
>>>>>>>>>
>>>>>>>>> FormData output with the x-www-form-urlencoded mime type:
>>>>>>>>> formData.toUrlEncodedBlob(xhr.send)
>>>>>>>>>
>>>>>>>>>
>>>>>>> [Supplemental] FormData
>>>>>>> void toMultipartBlob(in callback)
>>>>>>> void toUrlEncodedBlob(in callback)
>>>>>>>
>>>> ...
>>>>
>>>>> xhr.send(formData) would be the same as:
>>>>> formData.toMultipartBlob(function(blob) { xhr.send(blob); });
>>>>>
>>>>>
>>>> Google's Picasa, and various other web apis accept multipart/related
>>>> input.
>>>> Given that we don't want a method for each output type supported, I think
>>>> a
>>>> generic method would better serve authors.
>>>>
>>>> [Supplemental] FormData
>>>>   void toBlob(in FileCallback, in optional DOMString type, in any...
>>>> args);
>>>>
>>>> The default type for FormData would be multipart/form-data.
>>>> Vendors would be encouraged to support these, in addition:
>>>> application/x-www-form-urlencoded
>>>> multipart/related
>>>>
>>> What is multipart/related? Is that something supported by browsers? It
>>> doesn't appear supported by gecko, and it's certainly not supported
>>> for form submission in Gecko.
>>>
>>>
>> No, it's not supported by browser forms.
>>
>> I'm trying to extend the FormData object, because it's a handy object for
>> building up POST types used with XHR.
>> Since FormData supports Blob append, it'd be nice to support the various
>> services that use types other than multipart/form-data.
>>
>> Currently, FormData is all or nothing... so when interfacing with various
>> web services, I have to go back to re-creating the mime message from
>> scratch. Not a big deal, but it's frustrating to recreate the FormData
>> interface over-and over again.
>>
>> This could be easy, with an extended FormData:
>> http://code.google.com/apis/picasaweb/docs/2.0/developers_guide_protocol.html#PostPhotos
>>
>> var n = new FormData(); n.append(blob)...; n.toBlob(function(message) {
>> xhr.send(message); });
> It would make sense to me to add a getAsBlob function to FormData. We
> could also add support for other types of encodings than
> "multipart/form-data", either by using separate functions, or by using
> arguments to functions.
>
> However in all cases it seems much simpler to simply use return values
> rather than callbacks.
>

Encoding of a large blob might be a slow process, relative to the normal 
event loop.

multipart/form-data is a good place to start.

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.

Received on Wednesday, 31 August 2011 07:07:50 UTC