什么是“Upgrade-Insecure-Requests”HTTP 标头？

Question

我向 HTTP（非 HTTPS）站点发出 POST 请求，在 Chrome 的开发者工具中检查了该请求，发现它在将其发送到服务器之前添加了自己的标头：

Upgrade-Insecure-Requests: 1

在Upgrade-Insecure-Requests上搜索后，我只能找到information关于服务器发送this标头：

Content-Security-Policy: upgrade-insecure-requests

这似乎是相关的，但仍然非常不同，因为在我的情况下，客户端在 Request 中发送标头，而我发现的所有信息都是关于服务器发送相关标头的一个响应。

---

那么为什么 Chrome (44.0.2403.130 m) 会在我的请求中添加 Upgrade-Insecure-Requests，它有什么作用？

---

2016 年 8 月 24 日更新：

此标头已添加为W3C Candidate Recommendation，现在已得到官方认可。

对于那些刚刚遇到这个问题并且感到困惑的人，Simon East 的excellent answer 很好地解释了它。

Upgrade-Insecure-Requests: 1 标头曾经是 HTTPS: 1 in the previous W3C Working Draft，在正式接受更改之前，Chrome 已悄悄地重命名。

（在此过渡期间，当没有关于此标头的官方文档且 Chrome 是唯一发送此标头的浏览器时，提出了此问题。）

Answer 1

简短回答：它与Content-Security-Policy: upgrade-insecure-requests响应头密切相关，表明浏览器支持它（实际上更喜欢它）。

我花了 30 分钟的谷歌搜索，但我终于发现它隐藏在 W3 规范中。

之所以出现混淆，是因为规范中的标头是 HTTPS: 1，这就是 Chromium 实现它的方式，但在此之后 broke lots of websites that were poorly coded（尤其是 WordPress 和 WooCommerce），Chromium 团队道歉：

“我为损坏道歉；根据开发和测试期间的反馈，我显然低估了影响。”
— Mike West，Chrome Issue 501842

他们的解决方法是将其重命名为 Upgrade-Insecure-Requests: 1，此后规范已更新以匹配。

不管怎样，这是来自the W3 spec (as it appeared at the time)的解释...

HTTPS HTTP 请求标头字段向服务器发送一个信号表示客户端的偏好，以获得加密和经过身份验证的响应，并且 它可以成功处理升级不安全请求指令，以便尽可能无缝地提供该偏好。

...

当服务器在 HTTP 请求的标头中遇到此偏好时，它应该将用户重定向到所请求资源的潜在安全表示。

当服务器在 HTTPS 请求的标头中遇到此首选项时，如果请求的主机是 HSTS 安全或有条件的 HSTS 安全 [RFC6797]，它应该在响应中包含 Strict-Transport-Security 标头。

Answer 2

这解释了整个事情：

HTTP 内容安全策略 (CSP) 升级不安全请求 指令指示用户代理处理站点的所有不安全 URL （那些通过 HTTP 服务的）好像它们已被替换为安全的 URL（通过 HTTPS 提供的）。该指令适用于网络 具有大量不安全遗留 URL 的站点需要 重写。

upgrade-insecure-requests 指令在之前被评估 block-all-mixed-content ，如果设置了，后者实际上是 无操作。建议设置一个指令或另一个，但不要 两者都有。

upgrade-insecure-requests 指令不会确保用户 通过第三方网站上的链接访问您的网站将升级为 HTTPS 用于顶级导航，因此不会取代 Strict-Transport-Security (HSTS) 标头，仍应设置 具有适当的 max-age 以确保用户不受 SSL 剥离攻击。

来源：https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/upgrade-insecure-requests