9

I'm currently submitting an AJAX request on a web page to an API endpoint which works in Chrome and Firefox but not in IE.

The error message I'm getting in IE's dev tools is:

SEC7123: Request header x-custom-header was not present in the Access-Control-Allow-Headers list.
SCRIPT7002: XMLHttpRequest: Network Error 0x80070005, Access is denied.


Looking at the pre-flight OPTIONS request, here are some of the headers:

Origin: http://www.example.org
Access-Control-Request-Headers: content-type, accept, x-custom-header
Access-Control-Request-Method: GET

The response of the pre-flight shows this:

Access-Control-Allow-Headers: content-type, x-custom-header
Access-Control-Allow-Methods: GET, POST, PUT, OPTIONS
Access-Control-Allow-Origin: *


After this happens, the AJAX request isn't executed. It looks like IE cannot see that the header was returned in the response of the pre-flight request.


Any help would be greatly appreciated and if you need more information, please ask.

Thanks, James

James B.
  • 571
  • 5
  • 17
  • you need to test IE against a service you didn't create that you know have CORS support. It's impossible to tell what's wrong here. – mpm Aug 15 '18 at 11:06
  • @mpm I think that the issue is to do with the extra headers added to the request. As far as CORS support goes, this web service has support for it. The only issue is that there is now another header specified. As shown above in the pre-flight request, the "x-custom-header" is specified as an allowed header. However when making the AJAX call, it seems to be unable to find it. If you know of a web service which I can use to test this, please let me know. – James B. Aug 15 '18 at 11:13

2 Answers2

9

Okay, so I've found the solution. It turns out that IE enforces the headers' values to be in a comma separated list and the pre-flight request was responding with multiple headers with the same key. (Even though the W3 says that doing this should be okay). For example, the response could specify the Access-Control-Allow-Headers header twice:

Access-Control-Allow-Headers: content-type
Access-Control-Allow-Headers: accept

All of the dev tools (including IE's) on the network tab show the headers combined together as a comma separated list even though they're technically different headers with the same name. This is where the confusion came from.

This was discovered when using Postman to simulate the pre-flight requests and seeing the headers be returned as separate items.

Therefore, to fix this, ensure that the CORS headers such as "access-control-allow-headers" contain a comma separated list rather of the headers which are required since IE will only accept the first one sent. For example, the response should be:

Access-Control-Allow-Headers: content-type, accept
Nate Anderson
  • 18,334
  • 18
  • 100
  • 135
James B.
  • 571
  • 5
  • 17
  • I think I'm encountering the same issue. How were you able to verify that multiple headers with the same key are present in the pre-flight request in Postman? – ibrin Jun 09 '19 at 15:40
  • @ibrin it's been a while so sorry if this isn't 100% right but if you change the order you set the headers, they'll change in IE too. In Postman, if you send a request and look in Postman at the response headers, there will be multiple headers with the same Key, rather than just one with multiple values. – James B. Jun 10 '19 at 09:58
8

We ran into a CORS issue with Internet explorer and Access-Control-Allow-Methods, they are not compatible with allow '*' in OPTIONS response. Fix was to change the options response in our API gateway to use all methods

Adrian
  • 151
  • 2
  • 7