use*_*130 214 google-chrome http http-headers upgrade-insecure-requests
我向HTTP(非HTTPS)网站发出了POST请求,检查了Chrome开发者工具中的请求,发现它在将其发送到服务器之前添加了自己的标头:
Upgrade-Insecure-Requests: 1
Run Code Online (Sandbox Code Playgroud)
在搜索之后Upgrade-Insecure-Requests,我只能找到有关发送此标头的服务器的信息:
Content-Security-Policy: upgrade-insecure-requests
Run Code Online (Sandbox Code Playgroud)
这似乎是相关的,但仍然非常不同,因为在我的情况下,CLIENT在请求中发送标头,而我发现的所有信息都与SERVER在响应中发送相关标头有关.
那么为什么Chrome(44.0.2403.130米)会添加Upgrade-Insecure-Requests我的请求以及它的作用是什么?
此标题已被添加为W3C候选推荐标准,现已正式认可.
对于那些刚刚遇到这个问题并且感到困惑的人来说,Simon East 的出色答案很好地解释了这一点.
该Upgrade-Insecure-Requests: 1头曾经是HTTPS: 1 在之前的W3C工作草案,并改名悄然由镀铬前的变化成为正式受理.
(在此过渡期间,当此标题上没有官方文档且Chrome是唯一发送此标题的浏览器时,会询问此问题.)
Sim*_*ast 268
简短回答:它与Content-Security-Policy: upgrade-insecure-requests响应标头密切相关,表明浏览器支持它(实际上更喜欢它).
它花了我30分钟的谷歌搜索,但我终于发现它埋在W3规格.
混乱是因为规范中的标题是HTTPS: 1,而这正是Chromium实现它的方式,但在此之后打破了许多编码不佳的网站(特别是WordPress和WooCommerce),Chromium团队道歉:
"我为破损道歉;我显然低估了开发和测试期间反馈的影响."
- Mike West,Chrome问题501842
他们的修复是将其重命名为Upgrade-Insecure-Requests: 1,并且规范已经更新以匹配.
的
HTTPSHTTP请求报头字段将信号发送到所述服务器表达客户端的偏好用于加密和验证的响应,并且它可以成功地处理升级不安全-请求指令,以使该偏好尽可能无缝提供....
当服务器在HTTP请求的标头中遇到此首选项时,它应该将用户重定向到所请求资源的潜在安全表示.
当服务器在HTTPS请求的标头中遇到此首选项时,
Strict-Transport-Security如果请求的主机是HSTS安全的或有条件的HSTS安全[RFC6797] ,它应该在响应中包含一个标头.
这解释了整个事情:
HTTP Content-Security-Policy (CSP) upgrade-insecure-requests 指令指示用户代理将站点的所有不安全 URL(通过 HTTP 提供的)视为已替换为安全 URL(通过 HTTPS 提供的)。该指令适用于具有大量需要重写的不安全旧 URL 的网站。
upgrade-insecure-requests 指令在 block-all-mixed-content 之前进行评估,如果它被设置,后者实际上是一个空操作。建议设置一个指令或另一个,但不要同时设置。
upgrade-insecure-requests 指令不会确保通过第三方网站上的链接访问您网站的用户将升级到 HTTPS 以进行顶级导航,因此不会替换 Strict-Transport-Security (HSTS) 标头,后者仍应设置适当的 max-age 以确保用户不会受到 SSL 剥离攻击。
来源:https : //developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Security-Policy/upgrade-insecure-requests