- From: Boris Zbarsky <bzbarsky@MIT.EDU>
- Date: Thu, 17 Mar 2011 11:43:11 -0400
- 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 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 [2] https://bugzilla.mozilla.org/show_bug.cgi?id=642463
Received on Thursday, 17 March 2011 15:43:47 UTC