IE 10 on Win8 does not assign the correct status to XmlHttpRequest when the result is 401 - by Mike Clone

Status : 

  Not Reproducible<br /><br />
		The product team could not reproduce this item with the description and steps provided.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

ID 785990 Comments
Status Closed Workarounds
Type Bug Repros 15
Opened 5/1/2013 6:43:07 AM
Access Restriction Public


I have an expected scenario, where if a client is not authorized to a server resource the server responds with a status code = 401.

I was testing with CORS on IE10. IE10 does not assign the actual response status code (or probably other information) to the XmlHttpRequest after the ajax call completes. According to the W3C specification for XMLHttpRequest Level 2 ( HTTP status 401 should not be treated as a network error:

"In case of DNS errors, TLS negotiation failure, or other type of network errors, this is a network error. Do not request any kind of end user interaction.  This does not include HTTP responses that indicate some type of error, such as HTTP status code 410."

In Chrome and Firefox the expected status code of 401 is correctly set and visible with XmlHttpRequest.status = 401.

In IE 10 on win 8 the status code = 0.

The issue can be reproduced at and also at and at

This bug was first reported as
Sign in to post a comment.
Posted by Glibchyuk Ilya on 12/5/2016 at 12:29 AM
I have same problem, but reason is in other program, that integrated with IE. It was installed on my computer by AD-politics.
The software bad worked when RAM is full and IE worked like described in the ticket.
Posted by user-101 on 10/30/2015 at 6:10 AM
IE10 returns a status code 0 when the request is actually 401. SO make sure you accept a 0 as response code as well to keep it working on IE10
Posted by user-101 on 10/29/2015 at 7:22 AM
Is there a sollution? Why is the ticket marked as closed?
Cannot perform a CORS request on IE10 and WIndows 8.
Response code 403
Posted by MKJackson on 9/24/2015 at 7:56 AM
I can reproduce this on IE10.

Please can you fix it?

Pretty please?
Posted by truff on 4/30/2015 at 2:11 PM
I can reproduce this in IE11. In my case I am doing cross-origin request with withCredentials=true in XHR and all necessary CORS headers applied by the server. The server requires client certificates. The initial page requested prompts for the cert, as expected, then loads another page in an IFrame from a different origin which doesn't require authentication but is also retrieved via https. The iframe page makes the XHR cross-origin request back to the same server that served the main page. The preflight request is successful but the subsequent CORS request fails with XHR response status=0 and writes this to the developer console:
SCRIPT7002: XMLHttpRequest: Network Error 0x80070005, Access is denied.

Everything works fine in Chrome and Firefox. It also works in IE if Access Data Sources Across Domains is enabled.
Posted by dany0w on 10/30/2014 at 7:28 AM
I can also reproduce this issue. Please fix this.
Posted by I'm-Batman on 9/18/2014 at 2:49 PM

I just ran into this problem today. After trying a few workarounds, and some Googleing, I ended up here.
It turned out to just be a security level settings.
Whatever security zone your website is in (Internet Options > Security) make sure you ENABLE the following setting in your zone: Miscellaneous > Access data sources across domains.
Posted by aaronk6 on 4/29/2014 at 2:33 AM
10 users can reproduce this bug and it’s closed as "not reproducible"? Seriously? IE 10.0.9200.16519 is still affected.

BTW: Looks like this is fixed in IE 11. Please fix this in IE 10 as well. Thanks!
Posted by stevo9999 on 1/23/2014 at 12:57 PM
Please reopen this ticket. This is a serious bug, and will become a show stopper for anyone who wants to do pure html5 development in IE.

To reproduce this, you need to make an ajax call (I used jquery) to a web service of another domain. I implemented cors using web api.

When the service call returns a 401 status code, the xhr object in the ajax fail method doesn't get updated with the appropriate response code nor response body.
Posted by staticfive on 1/6/2014 at 3:42 PM
Can you guys stop dodging this question and actually fix something, please? This is a crippling issue. My API is kind enough to actually include the HTTP status code in the response, yet I have no way to get to it because you truncate a perfectly useful response for.......what reason exactly? And the captured traffic IN INTERNET EXPLORER shows that the response is 401, but the xhr status code shows 0. So, pray tell, what are we supposed to do?

Reopen this immediately and stop being okay with breaking the internet.
Posted by vincentjames501 on 10/15/2013 at 8:54 AM
As of IE 10.0.9200.16721, this is still an issue. This is easily reproducible and this bug needs to be reopened as it is very important as vrutberg noted. I've attached a basic Wireshark TCP stream of the communication showing the CORS preflight request and so on (I've changed the domain names to admin and api instead of their original domain names). As indicated above, the response status code comes back as 0 in IE and there is no response body to parse as this error is received:

SEC7118: XMLHttpRequest for http://api:8080/api/v1-DEV/distribution-lists required Cross Origin Resource Sharing (CORS).
SEC7119: XMLHttpRequest for http://api:8080/api/v1-DEV/distribution-lists required CORS preflight.
SCRIPT7002: XMLHttpRequest: Network Error 0x80070005, Access is denied.

Here is the capture:

OPTIONS /api/v1-DEV/distribution-lists HTTP/1.1
Accept: */*
Origin: http://admin:8080
Access-Control-Request-Method: GET
Access-Control-Request-Headers: accept, x-requested-with
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; WOW64; Trident/6.0)
Host: api:8080
Content-Length: 0
DNT: 1
Connection: Keep-Alive
Cache-Control: no-cache

HTTP/1.1 200 OK
Access-Control-Allow-Headers: origin, x-requested-with, accept, content-type
Access-Control-Allow-Methods: HEAD,POST,GET,PUT,DELETE,OPTIONS
Access-Control-Allow-Origin: *
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Server: Jetty(9.0.3.v20130506)
Set-Cookie: visited=yes
Content-Length: 0
Connection: keep-alive

GET /api/v1-DEV/distribution-lists HTTP/1.1
X-Requested-With: XMLHttpRequest
Accept: application/json, text/plain, */*
Referer: http://admin:8080/...
Accept-Language: en-US
Origin: http://admin:8080
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.1; WOW64; Trident/6.0)
Host: api:8080
DNT: 1
Connection: Keep-Alive
Cache-Control: no-cache

HTTP/1.1 401 Unauthorized
Access-Control-Allow-Headers: origin, x-requested-with, accept, content-type
Access-Control-Allow-Methods: HEAD,POST,GET,PUT,DELETE,OPTIONS
Access-Control-Allow-Origin: *
Content-Type: application/json;charset=UTF-8
Expires: Thu, 01 Jan 1970 00:00:00 GMT
Server: Jetty(9.0.3.v20130506)
Set-Cookie: visited=yes
Content-Length: 63
Connection: keep-alive

{"status":401,"type":"expired-token","message":"Expired Token"}
Posted by EricLaw [ex-MSFT] on 8/22/2013 at 12:34 AM
By default, Internet Explorer will automatically use the currently-logged-in user's credentials to respond to a credential challenge; 401s are handled "under the covers."

In your failing scenario, are you sending a request to the same host, or are you using CORS to send a request to a cross-origin host?
Posted by uglymunky on 7/29/2013 at 5:04 PM
I'm having the same problem using CORS with IE10. The server is sending a response of 401, with a response body (length == 506). IE10 recognizes in the network tab that it is a 401 but then, when I inspect the xhr object, status == 404 and the responseText is empty.

This ticket is currently showing as "closed - not reproducible". However, the problem is pretty consistent.
Posted by Aircraft5 on 6/25/2013 at 4:24 PM
I tried to reproduce this issue as described above on my Win8 and IE10. And yes, it happens. In IE 10 on win 8 the status code = 0.

Please, investigate this issue.
Posted by Microsoft on 6/21/2013 at 6:42 AM
Thank you for your feedback.

We are currently unable to reproduce this issue as described.

We value your feedback. If you have additional information that can help us recreate this issue — such as a specific url, more detailed steps, test results from different machines, or additional conditions — please reactivate the bug or submit a new bug with more details on how to reproduce the issue. You can also read the guidelines at regarding filing a good bug report.

Best regards,

The Internet Explorer Team
Posted by 6Wunderkinder on 5/8/2013 at 7:53 AM
We are also experiencing this same issue, it makes it impossible to determine if a user is unauthorized or simply lost internet connection.
Posted by Mike Clone on 5/7/2013 at 2:28 AM
As Viktor Rutberg points out there is no way for the calling code to detect that a 401 Unauthorized response has been returned and initiate authentication. This is inconsistent with the XmlHTTPRequest Level 2 specification:

"Otherwise, if authentication fails, user agents must not prompt the end user for their username and password. [HTTPAUTH] End users are not prompted for various cases so that authors can implement their own user interface."


Posted by vrutberg on 5/6/2013 at 12:05 AM

We are also experiencing this bug in our development, and I want to stress how serious of a bug this is for a modern cross-browser web application. We might be forced to drop support for IE10 due to this behaviour since there seems to be no way for application code to detect this state and work around it. This would be very unfortunate since this is is the first serious road-block for including Internet Explorer among our supported browsers.

* There are no XMLHttpRequest properties that can be used to detect this specific state
* The XMLHttpRequest object has no response headers left (possibly since IE10 considers it a network error and has thus dropped any such)

Viktor Rutberg
Posted by Microsoft on 5/2/2013 at 8:54 AM
Thank you for your feedback. We will be investigating this issue further.

Best regards,

The Internet Explorer Team