W3C home > Mailing lists > Public > public-webapi@w3.org > April 2006

Re: ISSUE-58: XMLHttpRequest.abort() should just reset the object

From: Jonas Sicking <jonas@sicking.cc>
Date: Thu, 13 Apr 2006 02:00:00 -0700
Message-ID: <443E1310.9050608@sicking.cc>
To: Jim Ley <jim@jibbering.com>
Cc: "Web APIs WG (public)" <public-webapi@w3.org>

>> If we do go to state 4 then things will look almost exactly like a 
>> successful response. The only difference is that .responseXML will be 
>> null, but that is already the case for a lot of consumers that send 
>> non-xml data.
> 
> I'd sort of disagree, the problem will manifest itself by the result not 
> being parseable as expected, as you say a null XML document is a 
> perfectly fine indicator of failure for XML expecting people - those 
> sending json will get a script error, those getting some other 
> structured format won't be able to parse it etc.

The problem is that many formats can't detect that they have been cut 
off. Even for something as strict as XML you could be loosing comments 
and PIs at the end of the document if the transation is terminated. The 
reason responseXML would be null in mozilla is that we'd get an internal 
error-notification from our network layer and would know not to even 
attempt parsing.

However that would not be possible for anyone using XMLHttpRequest since 
those notifications are never exposed.

So my point is that for many (most?) data formats it is not always 
possible to detect that the transaction failed.

> The only situation will be if the responseText is trivially directed to 
> the output, but as I say that's the reality anyway, this sort of error 
> handling simply isn't used.

I'm not sure I'm following you here...

/ Jonas
Received on Thursday, 13 April 2006 09:00:07 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 8 January 2008 14:18:54 GMT