W3C home > Mailing lists > Public > public-webapps@w3.org > January to March 2012

Reporting of CORS error in the XHR API callbacks

From: Tim Berners-Lee <timbl@w3.org>
Date: Fri, 20 Jan 2012 14:42:30 +0000
Message-Id: <99E249DF-259C-4BDD-9B15-7D9FC728F500@w3.org>
Cc: Thomas Roessler <tlr@w3.org>, "Michael(tm) Smith" <mike@w3.org>
To: public-webapps@w3.org


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


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?

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

This archive was generated by hypermail 2.3.1 : Friday, 27 October 2017 07:26:38 UTC