W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2010

Re: FormData questions

From: Dmitry Titov <dimich@chromium.org>
Date: Sat, 13 Feb 2010 18:02:51 -0800
Message-ID: <28040fc61002131802v315afec8k558ddbb08c1b08d5@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Webapps WG <public-webapps@w3.org>
On Fri, Feb 12, 2010 at 5:32 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> Hi WebApps fans!
>
> Working on implementing FormData and ran into a couple of questions.
>
> First of all, I assume that it is intended that a FromData object can
> be submitted several times. I.e. that the following code is ok:
>
> fd = new FormData;
> fd.append("name1", "foo");
> xhr1 = new XMLHttpRequest;
> xhr1.open(...);
> xhr1.send(fd);
> fd.append("name2", "bar");
> xhr2 = new XMLHttpRequest;
> xhr2.open(...);
> xhr2.send(fd);
>
> where the first XHR will send 1 name/value pair, and the second XHR
> will send 2. I do think this should be allowed, but I wanted to make
> sure others agreed.
>

What can be a reason to disallow this? FormData is just a collection of data
objects. So assuming those XHR objects are sync, the code should work as you
described.

Interesting question though - what happens if XHR is async and the content
of FormData changes while async operation is in progress. By analogy with
scenario when underlying file of Blob object changes while async reading
operation is in progress, would it be reasonable to fail the send and return
'error' ProgressEvent?


>
>
> Second, what encoding should be used when submitting a FromData
> object? A few options are:
> * Always use UTF-8
> * Allow a mimetype to be set on the FormData object, using a property
> or constructor argument
> * Use the charset mime parameter specified on the content-type header
> set using xhr.setRequestHeader
>
>
Having a way to specify encoding could be only useful for writing client
code against legacy site that takes charset-encoded form data and ignores
the charset parameter of content-type header of the request. That seems rare
these days. It would be way simpler to only deal with UTF-8, imo.


> I think the last one would be a pain for authors and for implementors.
>
>
> Lastly, there is a bug in the spec where it says that the mimetype
> should be "multipart/form-data". It needs to be "multipart/form-data;
> boundary=" plus the boundary used while encoding. This also brings up
> the question what to do if a Content-Type header has already been set.
> Should a boundary mime parameter be added, or is the server side
> simply out of luck and won't get to know what the boundary is?
>
> / Jonas
>
>
Received on Sunday, 14 February 2010 02:03:22 GMT

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