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, 24 Aug 2011 12:57:59 -0700
Message-ID: <4E5557C7.6020508@jumis.com>
To: Anne van Kesteren <annevk@opera.com>
CC: WebApps WG <public-webapps@w3.org>
On 8/24/2011 1:33 AM, Anne van Kesteren wrote:
> On Tue, 23 Aug 2011 20:44:15 +0200, Charles Pritchard 
> <chuck@jumis.com> wrote:
>> Is there any interest in supporting application/x-www-form-urlencoded ?
>>
>> It would of course lose any carried content types or file names from 
>> Blobs. urlencoding is certainly inefficient, and it's something that 
>> can be done in JS as things currently stand.
>> It would help to send urlencoded posts to services that don't support 
>> multipart.
>
> Examples of such services would be useful here. (That would still 
> accept urlencoded files.)

A URL encoded post; that it would use a blob as the source of one of the 
values is secondary.
The idea is to improve the FormData interface, so that 
xhr.send(FormData) can support x-www-form-urlencoded quickly/easily.

>
>
>> Prpoposed:
>>
>> FormData output with the x-www-form-urlencoded mime type:
>> formData.toUrlEncodedBlob(xhr.send)
>>
>> If going down the blob path, these two would have the same end-result:
>> formData.toMultipartBlob(xhr.send)
>> xhr.send(formData);
>
> What kind of API-style is this?
>
[Supplemental] FormData
void toMultipartBlob(in callback)
void toUrlEncodedBlob(in callback)

The first would create a multipart mime message, in a blob, and run the 
callback with the blob as the first argument,
the second would create a urlencoded message, in a blob, and also run 
the callback.
They'd set the appropriate content type on generated blob.


-Charles
Received on Wednesday, 24 August 2011 19:58:29 GMT

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