Q: Can we add Access-Control-Allow-Private-Network header to IIS CORS module responses? Chrome 98 introduces a new CORS scenario with Private Network Access.
https://developer.chrome.com/blog/private-network-access-preflight/
Our application is accessed on internal URLs, but also exposed to the internet by a cloud proxy, using the same URLs (different public vs internal DNS).
The implementation details has an unexpected issue for us with Chrome 98.  Users who access from the field/out of the office will resolve our page as a "public" page.  They then return to the office and continue working - those URLs are now recognized as "private" URLS, even though they're the same origin.  This worked wonderfully up to Chrome 98.
Contrary to what the Chrome blog article says, when the server is not handling the pre-flight requests, the requests fail immediately in Chrome 98.  (And would start failing in Chrome 101 as I understand it, either way).  Currently, users are forced to clear their cache in order to continue working when they come back to the office.
From the chromium issues log, I see others are having similar issues with some VPN scenarios.
The web application is a Microsoft Dynamics (CRM/365, 8.2) application running in IIS.  I don't have control to force it to handle the OPTIONS pre-flight request and return a 200 or 204.
I've tested the IIS CORS module and that works great for getting CORS added to an application I don't control and returning an expected response status code.  However, it doesn't appear to have anyway to control anything but the Access-Control-Allow-Origin, Access-Control-Allow-Credentials, Access-Control-Allow-Methods, Access-Control-Allow-Headers, and Access-Control-Max-age response headers.
For this new Chrome feature, we need to return:
Access-Control-Allow-Private-Network: true

header.
I've tried adding the header to the web.config customHeaders, but it doesn't (and didn't expect it to) work - as I believe CORS handles the request entirely before this is even considered.

A: Through further testing, the only solution I've found is to avoid the IIS CORS module and set all the response headers through customHeaders of web.config.  The fact that our application responds with a 400 status code to preflight requests did not cause any issues.  At least at this time, it looks like Chromium is only looking at the response headers and not status code.
<add name="Access-Control-Allow-Origin" value="https://app.example.com" />
<add name="Access-Control-Allow-Methods" value="GET, PUT, POST, PATCH, DELETE" />
<add name="Access-Control-Allow-Headers" value="*" />
<add name="Access-Control-Allow-Credentials" value="true" />
<add name="Access-Control-Allow-Private-Network" value="true" />

