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

Upgrade-Insecure-Requests: 1

在对Upgrade-Insecure-Requests进行搜索之后，我只能找到关于发送这个头文件的服务器的信息：

Content-Security-Policy: upgrade-insecure-requests

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

---

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

---

2016-08-24更新：

此标题已添加为W3C候选推荐标准，现已正式确认。

对于刚刚遇到这个问题并且感到困惑的人来说，Simon East的出色解答很好地解释了这一点。

Upgrade-Insecure-Requests: 1标题曾经在先前的W3C工作草案中为HTTPS: 1 ，并且在更改正式接受之前由Chrome 悄然重命名。

（在这个过渡期间，当这个标题没有官方文档时，这个问题被问到，Chrome是唯一发送这个头文件的浏览器。）

---

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

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

混乱是因为规范中的头文件是HTTPS: 1 ，这就是Chromium如何实现它的，但是在这之后打破了很多编码不好的网站（尤其是WordPress和WooCommerce），Chromium团队对此表示歉意：

“我为破坏道歉，我显然低估了在开发和测试期间基于反馈的影响。”
- 迈克韦斯特，在Chrome问题501842

他们的修正是将其重命名为Upgrade-Insecure-Requests: 1 ，并且该规范已经更新为匹配。

无论如何，这里是来自W3规范的解释（就像它当时出现的那样）......

HTTPS HTTP请求标头字段向服务器发送一个信号， 表示客户对加密和认证响应的偏好 ，并且它可以成功处理upgrade-insecure-requests指令 ，以使该偏好尽可能无缝地提供。

...

当一个服务器在一个HTTP请求的头文件中遇到这个首选项时，它应该将用户重定向到被请求的资源的一个潜在的安全表示。

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

---

这解释了整个事情：

HTTP Content-Security-Policy（CSP）upgrade-insecure-requests指令指示用户代理将所有站点的不安全URL（通过HTTP提供的URL）视为已被替换为安全URL（通过HTTPS提供的URL）。 此指令适用于需要重写大量不安全的旧版URL的网站。

upgrade-insecure-requests指令在block-all-mixed-content之前被评估，如果被设置，后者实际上是no-op。 建议设置一个指令或另一个指令，但不能同时设置。

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

链接地址: http://www.djcxy.com/p/42253.html

上一篇: What is the "Upgrade

下一篇: SERVER['HTTP