Firefox与Safari中Service Worker请求未携带自定义HTTP头如何解决？

排查步骤 #

• 确认请求模式是否被不当设置：同域请求默认不需要显式配置mode: 'cors'，Firefox、Safari对同域+强制cors模式的组合处理逻辑和Chrome存在差异，可在fetch调用前打印Request.mode确认是否有其他逻辑意外修改了请求模式。
• 校验CORS响应头完整性：即使Access-Control-Allow-Headers已经包含自定义头，还要确认OPTIONS响应的Access-Control-Allow-Origin没有使用通配符*，Access-Control-Allow-Credentials配置和请求是否携带凭证的逻辑完全匹配，Firefox和Safari对CORS头的校验规则比Chrome严格，任意配置不匹配都会静默丢弃自定义头。
• 确认自定义头命名合规：检查头名没有使用Proxy-、Sec-等浏览器保留的头前缀，这类前缀的头会被浏览器直接禁止修改。
• 核查Service Worker作用域：确认Service Worker的注册scope完全覆盖目标请求的路径，Firefox、Safari对超出scope的请求会静默丢弃自定义头配置，Chrome对该场景的限制更宽松。
• 排除扩展拦截影响：禁用所有广告拦截、隐私保护类浏览器扩展后复测，Firefox和Safari的扩展权限机制允许扩展在Service Worker层修改请求，可能会误删自定义头。

修复方案 #

• 移除同域请求的显式cors配置：同域请求默认使用same-origin模式即可，修改后无需触发OPTIONS预检，自然规避头校验问题，示例代码：

fetch(Request, {
    mode: 'same-origin',
    headers: {
      'my-custom-header': 'a value'
    }
  });

如果业务确实需要使用cors模式，确保OPTIONS响应的Access-Control-Allow-Origin精确匹配当前站点域名，不要使用通配符。

• 克隆不可变请求对象后修改头：Service Worker中接收到的原始Request对象是冻结的不可变对象，Firefox、Safari不支持直接修改这类对象的头配置，需要先克隆生成新请求再修改：

// 先克隆原始请求，合并原有头和自定义头
const modifiedRequest = new Request(Request, {
  headers: {
    ...Object.fromEntries(Request.headers.entries()),
    'my-custom-header': 'a value'
  }
});
fetch(modifiedRequest);

• 清理历史缓存干扰：注销现有Service Worker、清除站点所有缓存后再复测，避免旧的Service Worker逻辑或缓存规则影响测试结果。
• 升级浏览器版本：低于91版本的Firefox、低于15.4版本的Safari存在Service Worker自定义头处理的已知底层bug，升级到稳定最新版本可直接规避这类问题。

内容的提问来源于stack exchange，提问作者Hasan Genc