更新时间:2022-03-03 22:46:18
简答:与 Content-Security-Policy: upgrade-insecure-requests
响应头密切相关,表示浏览器支持它(实际上更喜欢它).
Short answer: it's closely related to the Content-Security-Policy: upgrade-insecure-requests
response header, indicating that the browser supports it (and in fact prefers it).
我花了 30 分钟的谷歌搜索,但我终于发现它隐藏在 W3 规范中.
It took me 30mins of Googling, but I finally found it buried in the W3 spec.
混淆是因为规范中的标头是 HTTPS: 1
,这就是 Chromium 实现它的方式,但是在此之后 破坏了许多编码不佳的网站(尤其是 WordPress 和 WooCommerce),Chromium 团队道歉:
The confusion comes because the header in the spec was HTTPS: 1
, and this is how Chromium implemented it, but after this broke lots of websites that were poorly coded (particularly WordPress and WooCommerce) the Chromium team apologized:
我为损坏道歉;根据开发和测试期间的反馈,我显然低估了影响."
— Mike West,在 Chrome 问题 501842
"I apologize for the breakage; I apparently underestimated the impact based on the feedback during dev and beta."
— Mike West, in Chrome Issue 501842
他们的解决方法是将其重命名为 Upgrade-Insecure-Requests: 1
,此后规范已更新以匹配.
Their fix was to rename it to Upgrade-Insecure-Requests: 1
, and the spec has since been updated to match.
无论如何,这是来自 W3 规范的解释strong>(当时出现)...
Anyway, here is the explanation from the W3 spec (as it appeared at the time)...
HTTPS
HTTP 请求标头字段向服务器发送一个信号表示客户端的偏好,以获得加密和经过身份验证的响应,并且 它可以成功处理upgrade-insecure-requests 指令,以使该偏好尽可能无缝地提供.
The
HTTPS
HTTP request header field sends a signal to the server expressing the client’s preference for an encrypted and authenticated response, and that it can successfully handle the upgrade-insecure-requests directive in order to make that preference as seamless as possible to provide.
...
当服务器在 HTTP 请求的标头中遇到此偏好时,它应该将用户重定向到所请求资源的潜在安全表示.
When a server encounters this preference in an HTTP request’s headers, it SHOULD redirect the user to a potentially secure representation of the resource being requested.
当服务器在 HTTPS 请求的标头中遇到此首选项时,如果请求的主机是 HSTS 安全或有条件的 HSTS 安全 [RFC6797],它应该在响应中包含 Strict-Transport-Security
标头].
When a server encounters this preference in an HTTPS request’s headers, it SHOULD include a Strict-Transport-Security
header in the response if the request’s host is HSTS-safe or conditionally HSTS-safe [RFC6797].