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

[XHR2] load events on XMHttpRequestUpload

From: Boris Zbarsky <bzbarsky@MIT.EDU>
Date: Thu, 17 Mar 2011 11:43:11 -0400
Message-ID: <4D822C0F.6000206@mit.edu>
To: public-webapps@w3.org
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

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
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=642463
Received on Thursday, 17 March 2011 15:43:47 UTC

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:30 UTC