什么是“升级不安全请求"?HTTP 标头? [英] What is the "Upgrade-Insecure-Requests" HTTP header?

问题描述

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

I made a POST request to a HTTP (non-HTTPS) site, inspected the request in Chrome's Developer Tools, and found that it added its own header before sending it to the server:

Upgrade-Insecure-Requests: 1

在 Upgrade-Insecure-Requests 上搜索后，我只能找到 关于发送 this> 标题:

After doing a search on Upgrade-Insecure-Requests, I can only find information about the server sending this header:

Content-Security-Policy: upgrade-insecure-requests

这似乎是相关的，但仍然非常不同，因为在我的情况下，客户端在 Request 中发送标头，而我发现的所有信息都是关于服务器发送相关标头的一个响应.

This seems related, but still very different since in my case, the CLIENT is sending the header in the Request, whereas all the information I've found is concerning the SERVER sending the related header in a Response.

那么为什么 Chrome (44.0.2403.130 m) 将 Upgrade-Insecure-Requests 添加到我的请求中，它有什么作用?

So why is Chrome (44.0.2403.130 m) adding Upgrade-Insecure-Requests to my request and what does it do?

此标头已被添加为 W3C候选推荐，现已获得官方认可.

This header has since been added as a W3C Candidate Recommendation and is now officially recognized.

Simon East 的优秀答案很好地解释了那些刚刚遇到这个问题并感到困惑的人.

For those who just came across this question and are confused, the excellent answer by Simon East explains it well.

Upgrade-Insecure-Requests: 1 标头曾经是 HTTPS: 1 在之前的 W3C 工作草案中，并被 Chrome 悄悄地重命名在更改被正式接受之前.

The Upgrade-Insecure-Requests: 1 header used to be HTTPS: 1 in the previous W3C Working Draft and was renamed quietly by Chrome before the change became officially accepted.

(在此过渡期间，当没有关于此标头的官方文档且 Chrome 是唯一发送此标头的浏览器时，提出了此问题.)

(This question was asked during this transition when there were no official documentation on this header and Chrome was the only browser that sent this header.)

推荐答案

简答:与 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 规范(当时出现)...

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].

这篇关于什么是“升级不安全请求"?HTTP 标头?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！