- From: Tim Berners-Lee <timbl@w3.org>
- Date: Fri, 20 Jan 2012 14:42:30 +0000
- To: public-webapps@w3.org
- Cc: Thomas Roessler <tlr@w3.org>, "Michael(tm) Smith" <mike@w3.org>
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