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

查看:613
本文介绍了什么是“升级 - 不安全 - 请求” HTTP标头?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

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

  Upgrade-Insecure-Requests:1 

在搜索 Upgrade-Insecure-Requests 后,我只能找到有关发送的服务器的信息

  Content-Security-Policy:upgrade-insecure-requests 

这看起来很相关,但仍然非常不同,因为在我的情况中,CLIENT正在发送 Request ,而我发现的所有信息都与SERVER在 Response 中发送相关头文件有关。






那么为什么加入Chrome(44.0.2403.130米) Upgrade-Insecure-Requests 到我的请求中,它有什么作用?




更新2016-08-24:



此标题已添加为 W3C候选推荐标准,现已正式确认。 对于刚刚遇到此问题并且感到困惑的人们,Simon East的出色的回答很好地解释了这一点。


$ b $ Upgrade-Insecure-Requests:1 标题曾经是 HTTPS:1 在之前的W3C工作草案中 并在Chrome被正式接受之前被Chrome改名为

当没有官员时d在这个头文件中,并且Chrome是唯一一个发送这个头文件的浏览器。)

解决方案

Content-Security-Policy:upgrade-insecure-requests 响应头,表示浏览器支持它(事实上它更喜欢它)。



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

混乱是因为规范中的头文件是 HTTPS:1 ,这就是Chromium如何实现它的原因,但在此打破了很多编码不良的网站之后(特别是WordPress和WooCommerce)Chromium团队道歉:
$ b


我为破坏道歉;我显然低估了基于dev期间反馈的影响和测试版。

- Mike West, Chrome Issue 501842


它们的修复方法是将其重命名为 Upgrade-Insecure-Requests: 1 ,并且规范已经更新为匹配。



无论如何,这里是 W3规范(因为它当时出现) ...


HTTPS HTTP请求标头字段向服务器发送一个信号,表示客户的首选项,用于加密和已验证的响应,并且它可以成功处理upgrade-insecure-requests指令



...



当服务器遇到此偏好时一个HTTP请求的头文件,它应该将用户重定向到被请求资源的潜在安全表示。



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


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

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

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.


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


Update 2016-08-24:

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

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

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.

(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.)

解决方案

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

It took me 30mins of Googling, but I finally found it buried in the W3 spec.

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:

"I apologize for the breakage; I apparently underestimated the impact based on the feedback during dev and beta."
— Mike West, in Chrome Issue 501842

Their fix was to rename it to Upgrade-Insecure-Requests: 1, and the spec has since been updated to match.

Anyway, here is the explanation from the W3 spec (as it appeared at the time)...

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.

...

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.

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屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆