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

Re: FormData questions

From: Michael Nordman <michaeln@google.com>
Date: Fri, 26 Feb 2010 11:19:27 -0800
Message-ID: <fa2eab051002261119g6ae6023ak9f8341fe836a446c@mail.gmail.com>
To: Jonas Sicking <jonas@sicking.cc>
Cc: Dmitry Titov <dimich@chromium.org>, Webapps WG <public-webapps@w3.org>
Horray for FormData! My $0.02

* UTF8 always

* Sending initiates the POST of a snapshot of the FormData at the time send
is called, subsequent modifications to the FormData don't affect what is
asyncly being sent, but do affect subsequent sends of the modified FormData.

* XHR.send(formData) always sets the response Content-Type including the
boundary tag used for the multipart encoding, overwriting any previously set
value. Hmmm... perhaps send() should throw an exception if there is a
previously set header value to make it more clear that callers shouldn't be
setting the Content-Type when sending() this class of object.

On Sun, Feb 14, 2010 at 7:32 PM, Jonas Sicking <jonas@sicking.cc> wrote:

> On Sun, Feb 14, 2010 at 6:04 PM, Dmitry Titov <dimich@chromium.org> wrote:
> >
> >
> > On Sat, Feb 13, 2010 at 6:44 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> >>
> >> On Sat, Feb 13, 2010 at 6:02 PM, Dmitry Titov <dimich@chromium.org>
> wrote:
> >> > 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.
> >>
> >> It complicates implementation a tiny amount, but IMHO not enough to
> >> disallow it.
> >>
> >> > 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?
> >>
> >> I don't think raising an 'error' event should be correct, no. In my
> >> example above I think the two requests should succeed successfully,
> >> and the first one should submit one name/value pairs, and the second
> >> should submit two.
> >
> > Does it mean that implementation should basically produce actual form
> data
> > synchronously (do a deep copy) at the moment of xhr.send() even if the
> xhr
> > is asynchronous? In case FormData includes Blobs backed by files on the
> disk
> > it may be prohibitive.
>
> I believe the text (non-Blob) data should be synchronously copied,
> yes. The Blob data needs no special handling beyond what you already
> have to do.
>
> The way we implement this in Firefox is that we create a multiplex
> data stream which consists of textual data mixed with Blob-backed
> data. So we create a stream implementation that will alternately read
> from in memory textual data, alternately from one or more Blobs.
>
> The object we create synchronously upon the call to send() just
> contains the text data and pointers to various Blobs. While this
> object is created synchronously, no data is read from the Blob. Once
> the network code reads from the stream, data is asynchronously read
> from the Blob.
>
> Don't know what setup you have for normal form submissions, so I'm not
> sure if you can duplicate this behavior exactly.
>
> Another way to look at it is that for the following code:
>
> fd = new FormData;
> fd.append("foo", "bar");
> fd.append("name", myFile);
>
> This synchronously creates a FormData object that contains enough
> information to submit both textual data and a Blob. And since you can
> create that information synchronously, you should for the following
> code
>
> xhr.send(fd);
>
> be able to synchronously create a clone of the fd that similarly
> contains enough information to submit both textual and Blob data, and
> then set up to transmit that clone.
>
> / Jonas
>
>
Received on Friday, 26 February 2010 19:19:56 GMT

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