且构网

分享程序员开发的那些事...
且构网 - 分享程序员编程开发的那些事

什么是“升级不安全请求"?HTTP 标头?

更新时间: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].