- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 13 Apr 2006 02:00:00 -0700
- 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 UTC