Reporting of CORS error in the XHR API callbacks

Reading

http://dvcs.w3.org/hg/xhr/raw-file/tip/Overview.html#network-error

it isn't obvious to me how the fact that a cross-site-scripting violation
has occurred.  The CORS spec

http://dvcs.w3.org/hg/cors/raw-file/tip/Overview.html#cross-origin-request-status

suggests the error should be treated like a network error, but IMHO
it is really important for the code using the XHR to be able simply
and unambiguously to know when the CORS cross-origin-request-status
is the problem, as opposed to any other network error.
(It is also important that this can be passed on the to a user, so when the
user is on the phone with customer support, the latter can understand what has happened).

There of course places where XHR is used and there is no cross-sitescripting
security needed

1)  in a browser extension
2)  in node.js code trusted apps 
3)  in web apps when web apps can, in I hope the near future, be installed, and flagged as trusted code

Therefore it is reasonable to write code in which the attempt is made, a CORS error recognized,
and alternative recourse taken (such as going through a proxy).

Should a new set of error codes such as 9XX be used for client-internal errors like this, I wonder?
Should there be a new value or status combined with readyState = 4?
Many bits of code just wait for readyState = 4 at the moment and then just check status.

What do current browsers do?

Tim

Received on Friday, 20 January 2012 14:42:41 UTC