Re: [XHR2] load events on XMHttpRequestUpload

Hey Maciej, Kenneth, opinions? (Or know anyone who does.)

On Thu, 17 Mar 2011 16:43:11 +0100, Boris Zbarsky <bzbarsky@mit.edu> wrote:
> 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


-- 
Anne van Kesteren
http://annevankesteren.nl/

Received on Tuesday, 21 June 2011 16:05:22 UTC