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

Upgrade-Insecure-Requests: 1

在搜索之后Upgrade-Insecure-Requests，我只能找到有关发送此标头的服务器的信息：

Content-Security-Policy: upgrade-insecure-requests

这似乎是相关的，但仍然非常不同，因为在我的情况下，CLIENT在Request中发送标头，而我发现的所有信息都与SERVER在Response中发送相关标头有关。

那么，为什么Chrome（44.0.2403.130 m）添加Upgrade-Insecure-Requests到我的请求中，它有什么作用？

更新2016-08-24：

此标头已被添加为W3C候选推荐标准，现已得到正式认可。

对于刚刚遇到这个问题并感到困惑的人，西蒙·伊斯特（Simon East）的出色回答很好地说明了这一点。

该Upgrade-Insecure-Requests: 1头曾经是HTTPS: 1 在之前的W3C工作草案，并改名悄然由镀铬前的变化成为正式受理。

（在此转换过程中，当此标头上没有官方文档，并且Chrome是发送此标头的唯一浏览器时，提出了此问题。）

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

我花了30分钟的时间进行谷歌搜索，但最终我发现它被埋在W3规范中。

之所以会感到困惑，是因为规范中的标头是HTTPS: 1，这就是Chromium的实现方式，但是在此之后，许多网站的编码不正确（尤其是WordPress和WooCommerce）中断了， Chromium团队道歉了：

“对于这种破坏我深表歉意；基于开发和测试期间的反馈，我显然低估了这种影响。”
— Mike West，在Chrome版本501842中

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

无论如何，这是W3规范的解释（当时是这样） ...

的HTTPSHTTP请求报头字段将信号发送到所述服务器表达客户端的偏好用于加密和认证响应，并且它可以成功地处理升级不安全-请求指令，以使该偏好尽可能无缝提供。

...

当服务器在HTTP请求的标头中遇到此首选项时，应将用户重定向到所请求资源的潜在安全表示形式。

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

这说明了整个问题：

HTTP内容安全策略（CSP）upgrade-insecure-requests指令指示用户代理将站点的所有不安全URL（通过HTTP服务的URL）视为已被安全URL（通过HTTPS服务的URL）代替。该指令适用于具有大量不安全的旧版URL且需要重写的网站。

在块全部混合内容之前评估upgrade-insecure-requests指令，如果已设置，则后者实际上是一个空操作。建议设置一个指令或另一个指令，但不要同时设置两个指令。

upgrade-insecure-requests指令不能确保通过第三方站点上的链接访问您的站点的用户将升级到HTTPS进行顶级导航，因此不会替换Strict-Transport-Security（HSTS）标头。仍应将其设置为适当的最大年龄，以确保用户不受SSL剥离攻击。

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