Re: [XHR2] load events on XMHttpRequestUpload

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>
>
>