- From: Charles Pritchard <chuck@jumis.com>
- Date: Tue, 23 Aug 2011 11:44:15 -0700
- To: Anne van Kesteren <annevk@opera.com>
- CC: Jonas Sicking <jonas@sicking.cc>, Michael Nordman <michaeln@google.com>, Adrian Bateman <adrianba@microsoft.com>, Julian Reschke <julian.reschke@gmx.de>, Alfonso MartÃnez de Lizarrondo <amla70@gmail.com>, Webapps WG <public-webapps@w3.org>
On 8/23/2011 3:08 AM, Anne van Kesteren wrote: > On Tue, 23 Aug 2011 10:18:19 +0200, Jonas Sicking <jonas@sicking.cc> > wrote: >> Yes. Where if the filename is excluded is left out it uses the >> File.name of the Blob (if the Blob is also a File), or "blob" (if the >> Blob is not a File). >> >> That leaves the question what to do if the filename is specified but >> is the empty string. I would argue that we should honor the call and >> use the empty string as name when submitting. > > Agreed: > > http://dev.w3.org/2006/webapi/XMLHttpRequest-2/#dom-formdata-append > > 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. Being able to grab a blob out of FormData has many messaging use cases. 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); -Charles
Received on Tuesday, 23 August 2011 18:44:42 UTC