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.

Received on Wednesday, 24 August 2011 19:58:29 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 20 October 2015 13:55:43 UTC