ASP.NET/IIS中Access-Control-Allow-Origin:*对部分请求无效问题

我来帮你梳理下问题的根源和解决办法：

你的核心问题在于，当前web.config里的CORS配置只会在请求携带Origin头时才返回Access-Control-Allow-Origin:*响应头，但Service Worker用sw-toolbox预缓存已被浏览器缓存的静态资源时，对应的请求可能不会带上Origin头，导致服务器不返回CORS响应头，进而触发浏览器的CORS错误。

为什么会出现这种情况？ #

IIS的<customHeaders>配置里的Access-Control-Allow-Origin是条件性触发的：只有当请求中存在Origin请求头时，服务器才会把这个响应头加进去。而当浏览器已经缓存了同源静态资源（比如HTML直接引用的JS/CSS），Service Worker发起预缓存请求时，浏览器可能会复用缓存的资源，或者发送不带Origin头的验证请求，这时候服务器就不会返回CORS头，导致Service Worker环境下的请求被浏览器判定为不符合跨源规则。

两种可行的解决方案 #

方案1：强制服务器始终返回CORS响应头

通过IIS的URL重写模块，强制给所有响应添加Access-Control-Allow-Origin:*头，不管请求是否携带Origin头。修改你的web.config如下：

<?xml version="1.0" encoding="utf-8"?>
<configuration>
  <system.webServer>
    <!-- 先移除可能存在的同名头，避免重复 -->
    <httpProtocol>
      <customHeaders>
        <remove name="Access-Control-Allow-Origin" />
      </customHeaders>
    </httpProtocol>
    <!-- 使用URL重写强制添加响应头 -->
    <rewrite>
      <outboundRules>
        <rule name="Force Access-Control-Allow-Origin">
          <match serverVariable="RESPONSE_Access-Control-Allow-Origin" pattern=".*" />
          <action type="Rewrite" value="*" />
        </rule>
      </outboundRules>
    </rewrite>
  </system.webServer>
</configuration>

这个方案的好处是不需要修改前端代码，从服务器层面彻底解决问题，确保所有响应都携带CORS头。

方案2：让预缓存请求强制带上Origin头

修改sw-toolbox的预缓存配置，让每个预缓存请求都以cors模式发送，这样浏览器会自动添加Origin头，服务器就会返回你配置的CORS响应头。示例代码如下：

// 修改sw-toolbox的预缓存配置
toolbox.precache([
  {
    url: '/path/to/your/js/app.js',
    options: {
      fetchOptions: {
        mode: 'cors'
      }
    }
  },
  {
    url: '/path/to/your/css/style.css',
    options: {
      fetchOptions: {
        mode: 'cors'
      }
    }
  },
  // 其他需要预缓存的资源
]);

这个方案适合不想修改服务器配置的场景，通过调整前端请求模式来触发服务器的CORS头返回。

额外提示 #

如果你的静态资源都是同源的，理论上不需要CORS头，但Service Worker的运行环境对缓存资源的验证规则更严格，强制添加CORS头可以避免这类缓存相关的跨源错误。

内容的提问来源于stack exchange，提问作者Naveed Ahmed