Is there a difference between the <cors> tag in web.config and this httpProtocol with Custom H-CodePudding

Currently in an ASP.NET Core MVC application, I am adding the following web.config to a site:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <cors enabled="true">
            <add origin="*" />
        </cors>
    </system.webServer>
</configuration>

But I have received feedback that some clients are needing to replace my cors tag with the following:

        <httpProtocol>
            <customHeaders>
                <add name="Access-Control-Allow-Origin" value="*" />
            </customHeaders>
        </httpProtocol>

I was wondering in what ways these are functionally different? They look to me like they would have the same result, but it doesn't seem that they do in practice.

Edit: I do wonder if the issue is that some of these servers are missing the IIS Cors Module. Reading the MSDN Documentation for the cors tag it seems to be equivalent to the second option as each is written.

CodePudding user response：

For simplest cases the two approaches are equivalent, but they have completely different results in complex scenarios, especially when your web app is protected by Windows authentication.

<cors> as part of IIS CORS module allows you to configure in such cases, while if you choose custom response headers you are fully on your own.