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
