Home Dashboard Directory Help
Search

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


Status: 

Closed
 as Not Reproducible Help for as Not Reproducible


Type: Bug
ID: 785990
Opened: 5/1/2013 6:43:07 AM
Access Restriction: Public
1
Workaround(s)
view
10
User(s) can reproduce this bug

Description

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://www.w3.org/TR/XMLHttpRequest2/#infrastructure-for-the-send-method) 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 http://codepen.io/anon/pen/HAbqm and also at http://plnkr.co/edit/E2lCflPDHHaQi7t79IeM?p=preview and at http://codepen.io/anon/pen/bwzcB

This bug was first reported as https://connect.microsoft.com/IE/feedback/details/773478/ie-10-on-win8-does-not-assign-the-correct-httpstatus-to-xmlhttprequest-when-the-result-is-401
Details
Sign in to post a comment.
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.

http://www.asp.net/web-api/overview/security/enabling-cross-origin-requests-in-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: *
Allow: HEAD,OPTIONS,GET,POST,PUT,DELETE
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 https://connect.microsoft.com/IE/content/content.aspx?ContentID=16254 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."

Regards

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

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)

Regards,
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
Sign in to post a workaround.
Posted by aaronk6 on 4/29/2014 at 2:46 AM
easyXDM (http://easyxdm.net/) can be used as a workaround for setups in which you’re able to deploy a public accessible HTML file to the target server (the server you want to access from your script using CORS).

Details here: http://easyxdm.net/wp/2010/03/17/cross-domain-ajax/
File Name Submitted By Submitted On File Size  
Capture.PNG (restricted) 6/25/2013 -