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
