CORS Preflight Request Issue on .Net Core API running locally on IIS Express

We are developing an application using a .Net Core (3.1.1) API and a react front-end. The application uses Windows Authentication. We are running the API framework-dependant on IIS. We initially had CORS issues but got everything working on IIS on the server by installing the CORS module and doing a transformation to the web.config on deploy. We also got basic CORS running on IIS Express by adding a <customheaders> section to the applicationhost.config file for Visual Studio. However, we are stuck on the preflight requests for PUT and DELETE actions when running locally on IIS Express.

Here is my lauchSettings.json file:

{
  "iisSettings": {
    "windowsAuthentication": true,
    "anonymousAuthentication": false,
    "iisExpress": {
      "applicationUrl": "http://localhost:xxxxx",
      "sslPort": xxxxx
    }
  },
  "$schema": "http://json.schemastore.org/launchsettings.json",
  "profiles": {
    "IIS Express": {
      "commandName": "IISExpress",
      "launchBrowser": true,
      "launchUrl": "api/values",
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development"
      }
    },
    "API": {
      "commandName": "Project",
      "launchBrowser": true,
      "launchUrl": "api/values",
      "environmentVariables": {
        "ASPNETCORE_ENVIRONMENT": "Development"
      },
      "applicationUrl": "http://localhost:xxxxx;https://localhost:xxxxx"
    }
  }

Here is the CORS section of our applicationhost.config file:

     <customHeaders>
        <clear />
        <add name="X-Powered-By" value="ASP.NET" />
        <remove name="Access-Control-Allow-Origin" />
        <add name="access-control-allow-origin" value="http://localhost:3000" />
        <add name="access-control-allow-headers" value="*" />
        <add name="access-control-allow-credentials" value="true" />
        <add name="access-control-allow-methods" value="get, post, put, delete, options" />
        <add name="access-control-max-age" value="600" />
      </customHeaders>

As I said, this works great for GET & POST, but isn't working for PUT or DELETE. We get the error:

Access to fetch at 'https://localhost:xxxx/api/blah/blahblah' from origin 'http://localhost:3000' has been blocked by CORS policy: Response to preflight request doesn't pass access control check: It does not have HTTP ok status.

I tried installing the CORS module locally (which fixed the issue on the server with IIS) but it requires the IIS 7 engine or above to run. I think that the basic issue is that the preflight request is being sent anonymously, and we have anonymous authentication disabled so we can use Windows Authentication - but short of rewriting the application to handle CORS and authentication in the application instead of letting IIS handle it - do I have any option for IIS Express?

Here are some resources I used to get me this far: https://davidsekar.com/asp-net/cors-development-in-localhost, https://docs.microsoft.com/en-us/aspnet/core/security/authentication/windowsauth?view=aspnetcore-3.1&tabs=visual-studio, https://blogs.iis.net/iisteam/introducing-iis-cors-1-0, http://blog.jonathanchannon.com/2013/09/16/enabling-cors-in-iisexpress/,

UPDATE

I may have solved it by adding the following to the applicationhost.json file in the system.WebServer section:

<rewrite>
            <globalRules>
                <rule name="Preflight" patternSyntax="Wildcard" stopProcessing="true">
                    <match url="*" />
                    <conditions>
                        <add input="{REQUEST_METHOD}" pattern="OPTIONS" />
                    </conditions>
                    <action type="CustomResponse" statusCode="200" statusReason="Preflight" statusDescription="Preflight" />
                </rule>
            </globalRules>
        </rewrite>

This basically just returns a custom 200 response to all OPTIONS requests. Wouldn't be ideal for production, but since this is just for running IIS Express locally, it should be fine. I'll post another update after more testing to confirm.

UPDATE 2 That did, in fact, correct the issue. Hope this helps save someone else some time....