Browser fails to recognize Access-Control-Allow-Origin if it is an IDN domain

Fixed Issue #8075637


marcus o.
Jul 4, 2016
This issue is public.
Found in
  • Microsoft Edge
  • Internet Explorer
Reported by 7 people

Sign in to watch or report this issue.

Steps to reproduce

This error seems to exist in both latest IE and latest Edge. The error occurs when you are on an IDN domain (My domain contains an ‘å’) and makes an XMLHTTP cross-origin request. On the server responding to the request you can set the Access-Control-Allow-Origin response header to the exact request origin, yet still it says the origin does not match, the only value you can set for it to work is wildcard (*).

I’ve attached an image with the console error.
I’m using english as my browser language, perhaps this only happens if you use a browser language which does not have that character.


2 attachments

Comments and activity

  • If you open network tab and click into the request, you can also see that the Origin request header has broken encoding, see attachment. In other browsers where it works the Origin header is set to the punycode URL

  • Steps to reproduce:

    1. Setup a server which is configured to allow and respond to CORS requests using the ‘Access-Control-Allow-Origin’ header, set it’s value to the requesting origin (which should mean it will allow all requests)
    2. Go to a website with punycode domain (e.g
    3. Open up the console in developer tools and make a POST request to your server (if jQuery is present as in the above domain, simply do it using
    4. You will now see that you get the error as shown in the IEBUGG2.png attachment above
    5. Try the same procedure in chrome/firefox (havent tested anyone else) and you’ll see everything works fine there
  • So you are just going to completely ignore this issue? We can’t secure our server from foreign domain requests using the ‘Access-Control-Allow-Origin’ header because of this bug and it only happens in IE and Edge

  • So you are just going to complete ignore this issue? We cant secure our server from foreign domain requests using the ‘Access-Control-Allow-Origin’ header because it would break our site with punycode domain in IE / Edge (and no other browser).

  • Microsoft Edge Team

    Changed Assigned To to “Brad E.”

  • Sorry about the delay in getting back to you with this bug report.

    Which version of Edge are you testing this out on?

    Also, the domain you provided does not seem to be active any longer. Can you provide another sample domain that we can use for the repro? The rest of my repro environment is ready to go.

    All the best,
    The MS Edge Team

  • We
    have not received a response with more details - this item of feedback will be
    closed soon unless we are able to obtain more information.

  • It doesnt matter if the domain is active, as long as the site responds (which the site i provided does), since you just need to get the browser to make a request with a punycode domain origin.

    1. open developer tools -> console
    2. go to
    3. in console enter

    You will now see an error in the console about the access-control-allow-origin not matching the server, even if you have configured your server so it does. In network tab you can also see the the origin has broken encoding

  • in 3. in my previous comment you should put your server URL inside post():

  • I have the same problem, I have done extensive testing and can confirm the problem only exists with IDN domains.

    In my case i use google re captcha, and it function with all browsers except for IE 11 where browser fails to recognize Access-Control-Allow-Origin


  • I see the same bug on cyrillic domains, namely here https://екатеринбург.рф/noname/vidzhet-uralbilet

    IE10 and IE11 do not recoginze the domain name returned in Access-Control-Allow-Origin header.

  • Correction.
    The URL demonstrating the bug is:

  • I am still not able to repro this in IE11 on Win 10 running build 14911.  I went to this site and threw a at it … Worked exactly as expected in both Edge and IE 11.  No errors.

  • Actually, upon reviewing the URL you gave again with Edge I do see the error you are reporting. We will investigate.

    All the best,
    The MS Edge Team

  • Microsoft Edge Team

    Changed Assigned To to “Venkat K.”

  • Thank you, Brad.

  • Microsoft Edge Team

    Changed Assigned To from “Venkat K.” to “Nicolas A.”

  • Any news, Microsoft?

  • We hit the same issue in Japan, is there any update?

  • I am also experiencing this bug, with a domain with ‘ø’ in it. The address bar is showing the punycoded version of the url, while request headers are sent with a noncoded version of the url.

  • Just experienced the same issue.

    I’ve tried responding with the punycode version and the raw version received from the client, neither of which work. Wildcard does work, but if you are sending a credentialed request, that request is denied because wildcards cannot be used for credentialed requests.

    Basically, if you’re using IE/Edge on a IDN-domain URL and use credentialed requests (cookies, for instance), you basically have no remedy.

    Unless someone at Microsoft can tell us some encoding or way to make the server respond with whatever IE/Edge expects to get back.

  • Marcus’ steps are correct. Here’s a small Node.js server that’ll listen on port 3000 and respond with the same origin that the browser sends:

    const http = require('http')  
    const port = 3000
    const server = http.createServer((request, response) => {  
      const origin = request.headers.origin
      if (origin) {
        console.log('Client sent origin: ', origin)
        response.writeHead(200, {
          'Vary': 'Origin',
          'Access-Control-Allow-Origin': origin,
          'Access-Control-Max-Age': '0'
      } else {
        response.setHeader('Cache-Control', 'no-cache, max-age=0')
      response.end(origin ? 'Yay cors!' : 'No origin passed')
    server.listen(port, err => {
      if (err) {
      console.log(`Server is listening on ${port}`)

    Save it to a file and run it with node, then open up your browser on some IDN-domain such as http://på (not my site, but any IDN-domain works). Open up the devtools and run this code to do a request against the local server:

    fetch('http://localhost:3000/').then(res => console.log(res)).catch(err => console.error(err.message))

    If you try it from Chrome or Firefox, the server will say:

    Client sent origin:

    While IE/Edge hitting it will yield:

    Client sent origin:  http://på
  • Microsoft Edge Team

    Changed Assigned To from “Nicolas A.” to “Brandon M.”

    Changed Title from “Browser fails to recognize Access-Control-Allow-Origin if it is an IDN domain” to “Browser fails to recognize Access-Control-Allow-Origin if it is an IDN domain”

    Changed Status to “Confirmed”

    Changed Assigned To from “Brandon M.” to “Ali A.”

    Changed Status from “Confirmed” to “Fixed”

  •  Thank you everyone for the feedback! We have fixed this bug and it should be available in an upcoming Windows Insider build.

  • Thanks for the fix! Is the problem fixed for both Edge and IE 11?

  • Microsoft Edge Team

    Changed Status from “Fixed” to “Fixed”

  • Thanks for the fix! Is the problem fixed for both Edge and IE 11?

    I have the same question: Which with update the users will get that fix? Windows 10 Fall Creators Update?

    And will it implemented in IE 11 too?

    Btw. thank you for the fix.

  • In which build is this implemented??? WHY IS THIS INFORMATION NOT POSTED HERE?

  • I can confirm it is still not fixed.

    Furthermore, IE/Edge sends incorrect (non-punycoded) values not only for Origin header, but also for Referer. I saw this bug for the first time as much as seven years ago, and it is still there. Here is a related bugreport in the Django tracker:

    And there is an issue in the Google Recaptcha repo, which also might be related to this:

  • I accept that this problem is not fixed. Incorrect values in response headers referer.

You need to sign in to your Microsoft account to add a comment.

Sign in