title: Recommended solution for AJAX, CORS, Chrome & HTTP error codes (401,403,404,500)
body: <p><strong>Background</strong> </p>
  
  <p><em>(If you are familiar with CORS, you might skip to the <strong>Question</strong> at the end)</em></p>
  
  <p>CORS [1] is a solution to allow browsers to permit access to resources from different domains. E.g. REST data backends using AJAX.</p>
  
  <p>It is well observed on the Internet that Chrome (and Webkit friends) do not handle HTTP authentication prompts when such a resource demands it. E.g. [2]
  ( this is to prevent the browser showing an auth login dialog on for example, a Web-Mail sign-in page when an image tags load fails with a 401 and needs credentials.  The user may be duped in to entering their webmail credentials)</p>
  
  <p>Chrome's behaviour in this situation is to drop the response, cancelling the request almost silently.</p>
  
  <p>In fact, Chrome will only let the response through normally if a 200 occurs; any other status code is swallowed and the AJAX call is aborted.</p>
  
  <p>If one uses jQuery to perform an Ajax request, and the remote site responds with an HTTP 401 status code, the request is cancelled and the ajax completes with an error, but the 401 code is missing.  It as if the connection died or a equivalent lower layer problem.</p>
  
  <p><em>The only website I've seen which mentions this caveat of CORS specifically is [1]</em></p>
  
  <blockquote>
    <p>Browers don't do a good job of reporting what went wrong when there is an error. 
    For example, Firefox reports a status of 0 and an empty statusText for all errors. 
    Browsers also report an error message to the console log, 
    but this message cannot be accessed from JavaScript. 
    When handling onerror, you will know that an error occurred, but not much else.</p>
  </blockquote>
  
  <p>You can disable this security by using a chrome startup flag - just to test both the backend is functioning 'normally' and one sanity hasn't been unduly affected by the loss of proper status codes. See [2]</p>
  
  <p><strong>Problem</strong></p>
  
  <p>What if the backend and front-end client code is supposed to use the 401 as part of it's authentication process? - any failures are just just mangled into one "error" output. </p>
  
  <p>For example: Upon issuing a request to authenticate - e.g. 2-legged OAuth token request -against a RESTful backend - which uses proper status codes - The client has no idea if: </p>
  
  <ul>
  <li><strong>401</strong> The user was not authenticated.</li>
  <li><strong>---</strong> The connection failed.</li>
  <li><strong>400</strong> There was a bad request.</li>
  <li><strong>500</strong> The server has a problem.</li>
  <li><strong>207</strong> There was no content after success.</li>
  </ul>
  
  <p>A backend of ours which was written <em>quite</em> RESTfully, following as many best practices as was deemed cost effective at the time; one of these was relying on proper HTTP status codes. 
  The Java REST Client we have working against has worked great.</p>
  
  <p>Now I have begun creating a Javascript client, for embedding in webpages - specifically using CORS, and we have hit the problem in Chrome etc. (Note Firefox <em>seems</em> fine, and we generally don't care for IE at present.)</p>
  
  <p><strong>Question</strong></p>
  
  <p>What have people done to work around these issues?<br>
  Is there anything that can be done to make CORS more suitable for trusted backends?</p>
  
  <p><strong>Links</strong></p>
  
  <ol>
  <li>CORS Tutorial: <a href="http://www.html5rocks.com/en/tutorials/cors/" rel="noreferrer">http://www.html5rocks.com/en/tutorials/cors/</a></li>
  <li>Chrome won't allow 401-triggered auth prompt for resources: <a href="http://code.google.com/p/chromium/issues/detail?id=81251" rel="noreferrer">http://code.google.com/p/chromium/issues/detail?id=81251</a></li>
  <li>--disable-web-security for Chrome: <a href="https://stackoverflow.com/questions/3102819/chrome-disable-same-origin-policy">Disable same origin policy in Chrome</a></li>
  </ol>