W3C home > Mailing lists > Public > public-webapps@w3.org > April to June 2011

Re: [XHR2] load events on XMHttpRequestUpload

From: Darin Fisher <darin@chromium.org>
Date: Tue, 21 Jun 2011 12:01:45 -0700
Message-ID: <BANLkTik9jOGWBmM8MvWaYE+qxoC4wGMOaF0WfWbvvgc53Gvg=Q@mail.gmail.com>
To: Boris Zbarsky <bzbarsky@mit.edu>
Cc: public-webapps@w3.org, "Tony Chang (Google)" <tony@chromium.org>
Hmm... this is curious.  I'm not sure that the Chrome behavior is
intentional.  I need
to investigate further.

Isn't there already a signal to tell you when response headers are
available?  Isn't it a
bit redundant for the upload complete notification to be tied to the same
signal?

To support the use case of showing a progress meter, it seems helpful to
know when
the browser has finished writing bytes on the wire.  It also seems like it
would be useful
for there to be a "resend" event indicating that the upload will be resent.
 Otherwise, one
has to guess this.

-Darin



On Thu, Mar 17, 2011 at 8:43 AM, Boris Zbarsky <bzbarsky@mit.edu> wrote:

> http://www.w3.org/TR/**XMLHttpRequest2/<http://www.w3.org/TR/XMLHttpRequest2/>section 3.6.9 near the end says:
>
>  If the request entity body has been successfully uploaded and the
>  upload complete flag is still false, queue a task to run these
>  substeps:
>
> We have implemented this in Gecko, but the result seems to be some
> confusion on the part of users of this API [1,2].  Furthermore, at least
> Chrome implements what those users expect, not what the spec currently
> specifies should happen.
>
> The fundamental problem is that you don't know whether the upload is
> "successful" until you get the start of the server's response.  In
> particular, if the server responds with a 401 or 307 the upload may well
> have to be redone.  And if the server never responds, then the upload may
> not have been successful: just because we put the bits on the wire doesn't
> mean the server got them.
>
> Therefore we fire "load" on XMHttpRequestUpload after we have gotten the
> initial part of the server response.  This is consistent with the text in
> the spec right now (and is incidentally easiest to do with our networking
> library, which doesn't really notify the consumer when it's done putting
> upload bits on the wire, for the same reasons: it's a misleading metric).
>
> The question is whether the spec should be relaxed to not require the
> upload is successful (in which case we'll change our implementation) or
> whether Chrome's implementation needs to change.  In the latter case the
> spec needs to be clearer about what "successful" means, obviously, since at
> least one implementor misinterpreted it.
>
> [1] https://bugzilla.mozilla.org/**show_bug.cgi?id=637002<https://bugzilla.mozilla.org/show_bug.cgi?id=637002>
> [2] https://bugzilla.mozilla.org/**show_bug.cgi?id=642463<https://bugzilla.mozilla.org/show_bug.cgi?id=642463>
>
>
Received on Tuesday, 21 June 2011 19:02:09 GMT

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