I believe that a zero status code can mean many things. In my case, I received a status code equal to zero due to the user leaving the page before the request-response cycle could end. You can also get a status code equal to zero if the connection to the server failed. I basically generalized this as a failure in the outgoing message from the sender. That is why it also offers cross-site requests and other reasons related to the client side.
W3 The XMLHttpRequest specification in section 4.8.1 states:
The status attribute should return the result of the following steps:
If the state is UNSENT or OPENED, return 0 and complete these steps.
If the error flag is set, return 0 and complete these steps.
Return the HTTP status code.
If I read the specification correctly, UNSENT and OPENED are states, the request may be before sending. And the error flag is set if:
The error flag indicates some type of network error or interrupt request ...
The problem with this status code is that the user interrupts the request from navigation, I do not consider this a condition of error, since this is a deliberate action of the user. Network problems I am considering a bug. For example, if a user invokes an action that results in an ajax request that has an error handler to redirect them to the error page. If the user had to leave the current page, canceling the request, from the point of view of ease of use, it makes no sense to redirect them to the page with an error. Implementing the specification is fine, except that I have not yet defined a way to know that the null status code was caused by an aborted request or for some other reason. If I could make a difference, I could take action.
EDIT: 03/18/2014
In response to a comment by @ariera on August 9, 2013, I talk about what was a workaround. However, the problem is that some time has passed since I decided this, and my memory is vague.
If I remember correctly, the idea of determining whether status code 0 was caused by the user indirectly interrupting the request was to put the error handling code in its own callback separately from the error callback. Then in the error callback you check if the status code is zero. If so, call the error callback in the wait delay, otherwise call the error callback. The idea here is that if the error code is zero, then a delay in processing this error allows the browser to actually navigate. Allowing browsers to navigate should clear any executable JavaScript, and therefore the error handler will not fire.
Now it is kludge and may not even work, as it is again, I really don’t remember the complexity of the problems, but I hope this leads someone else to the right path.