使用Fetch API的摘要认证在重定向场景下失效的问题求助

可行解决方案 #

1. 手动处理303重定向，放弃Fetch自动跳转 #

用Fetch的redirect: 'manual'选项接管重定向流程，针对新的跳转请求重新生成符合要求的Digest认证头：

// 初始化Digest客户端
const digestClient = new DigestClient('your-username', 'your-password');

// 发起初始POST请求，关闭自动重定向
digestClient.fetch('initial-post-url', {
  method: 'POST',
  body: JSON.stringify(yourPayload),
  redirect: 'manual'
})
.then(async (response) => {
  // 处理303重定向
  if (response.status === 303) {
    const redirectUrl = response.headers.get('Location');
    // 针对重定向URL发起新请求，让digest-fetch重新计算认证头
    return digestClient.fetch(redirectUrl, { method: 'GET' });
  }
  return response;
})
.then((finalRes) => finalRes.json())
.catch((err) => console.error('请求失败:', err));

这个方法最可靠，完全避开了Fetch自动重定向复用头的问题，让digest-fetch为每个请求单独生成正确的认证头（自动递增nc值）。

2. 修改digest-fetch源码，适配重定向场景 #

如果不想手动处理每个重定向，可以修改digest-fetch核心逻辑：

• 找到生成Authorization头的核心函数（比如generateDigestHeader类方法）
• 添加逻辑：检测到当前请求是重定向触发时，自动递增对应nonce的nc计数器，再生成新的认证头
• 注意维护每个nonce对应的独立nc计数，避免不同请求互相干扰

3. 临时禁用服务器端nc校验（不推荐） #

若有服务器配置权限，可临时关闭Digest认证的nc校验逻辑。但这会削弱重放攻击防护能力，仅作为应急方案，不建议长期使用。

问题根源 #

Fetch的自动重定向机制会缓存并复用原始请求的所有HTTP头，包括Authorization头。而Digest认证明确要求：

后续请求的十六进制请求计数器（nc）必须大于上次使用的值，同时可复用服务器nonce，但需要新的客户端nonce（cnonce）

digest-fetch当前实现未考虑Fetch自动重定向场景，不会在重定向时更新nc值；你尝试的带toString的对象方法无效，是因为Fetch在初始化请求时就会把所有头转换为字符串并缓存，重定向时不会重新调用toString生成新值。

内容的提问来源于stack exchange，提问作者Gunther Schadow