- From: Charles Pritchard <chuck@jumis.com>
- Date: Tue, 30 Aug 2011 23:29:13 -0700
- To: Anne van Kesteren <annevk@opera.com>
- CC: WebApps WG <public-webapps@w3.org>
On 8/30/2011 11:03 PM, Anne van Kesteren wrote: > On Tue, 30 Aug 2011 21:49:19 +0200, Charles Pritchard > <chuck@jumis.com> wrote: >> Many services use form-urlencoded for form data, though not for >> files, and typically not for large strings. >> Google's Picasa uses multipart/related instead of multipart/form-data. >> >> I believe that Google App engine has a few areas where POST is used >> with x-www-form-urlencoded only. I'm not certain. >> Many RPC services expect POST + form-urlencoded. >> >> Again, I realize that you're looking for specific, existing services, >> citations. It's going to take me some time to put that together. > > It also seems likely some of those will be updated to either make use > of FormData or provide a convenience library for authors. Having just > introduced FormData it seems somewhat premature to make it much more > complex. It's not even in all browsers yet. > > Yes, it's for convenience. These are long-standing RFC specs. FormData is already convenient, used with XmlHttpRequest. The FormData interface can be implemented in JS, for browsers that support xhr binary, though xhr arraybuffer is more efficient. I've had to use arraybuffer, when FormData is insufficient. That's fine, but I'd like to see these three widely used specs supported, through some means. This is minor work for vendors already supporting multipart/form-data. application/x-www-form-urlencoded: 1995 http://www.ietf.org/rfc/rfc1866.txt multipart/form-data: 1995 http://www.ietf.org/rfc/rfc1867.txt multipart/related: 1998 http://tools.ietf.org/html/rfc2387
Received on Wednesday, 31 August 2011 06:29:49 UTC