- From: Charles Pritchard <chuck@jumis.com>
- Date: Wed, 24 Aug 2011 12:57:59 -0700
- 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 UTC