2 回答
简短的回答：它与响应头密切相关Content-Security-Policy: upgrade-insecure-requests，表明浏览器支持它（实际上更喜欢它）。
我花了 30 分钟的谷歌搜索，但我终于发现它隐藏在 W3 规范中。
造成混乱是因为规范中的标头是HTTPS: 1，这就是 Chromium 实现它的方式，但是在这破坏了许多编码不佳的网站（尤其是 WordPress 和 WooCommerce）之后，Chromium 团队道歉：
“我为损坏道歉；我显然低估了基于开发和测试期间的反馈的影响。”
— Mike West，Chrome 问题 501842
他们的解决方法是将其重命名为Upgrade-Insecure-Requests: 1，并且规范已经更新以匹配。
无论如何，这是W3 规范的解释（当时出现） ......
HTTP 请求标
HTTPS头字段向服务器发送一个信号，表示客户端对加密和经过身份验证的响应的偏好，并且它可以成功处理 upgrade-insecure-requests 指令，以使该偏好尽可能无缝地提供。...
当服务器在 HTTP 请求的标头中遇到这种偏好时，它应该将用户重定向到被请求资源的潜在安全表示。
当服务器在 HTTPS 请求的标头中遇到此首选项时，
Strict-Transport-Security如果请求的主机是 HSTS 安全或有条件的 HSTS 安全 [RFC6797]，它应该在响应中包含一个标头。
这解释了整个事情：
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) 标头，该标头仍应设置适当的 max-age 以确保用户不会受到 SSL 剥离攻击。