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

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

From: Christophe Jolif <cjolif@ilog.fr>
Date: Thu, 13 Apr 2006 11:29:19 +0200
Message-ID: <443E19EF.208@ilog.fr>
To: Jim Ley <jim@jibbering.com>
CC: "Web APIs WG (public)" <public-webapi@w3.org>

Jim Ley wrote:
> 
> "Jonas Sicking" <jonas@sicking.cc>
>> In IE you can at least test for .status == 200 to test if things 
>> worked out ok. Even though the statuscode for various errors seem to 
>> be weird to say the least, at least they are different from the 
>> success codes.
>>
>> I actually think this is how we should do errorhandling for now since 
>> that should work with most existing content.
> 
> I would be content with this, but no-one else appeared to be in Oslo.
> 
>> 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.

Even though you can always imagine to find solution to workaround it. I 
think it is a bad idea to go to 4 without having a clear knowledge of 
what the status really is (successful or erroneous). Indeed bad or null 
XML can be due to a bug on the server, not necessarily a network error!

-- 
Christophe
Received on Thursday, 13 April 2006 09:28:21 GMT

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