当前位置 博文首页 > 、唐城：小唐表示很为难！Https访问地址仍然会出现【不安全】提
<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">可以在相应的页面的
里加上这句代码，意思是自动将http的不安全请求升级为httpsHTTPS 是 HTTP over Secure Socket Layer，以安全为目标的 HTTP 通道，所以在 HTTPS 承载的页面上不允许出现 http 请求，一旦出现就是提示或报错：
Mixed Content: The page at ‘https://www.taobao.com/‘ was loaded over HTTPS, but requested an insecure image ‘http://g.alicdn.com/s.gif’. This content should also be served over HTTPS.
HTTPS改造之后，我们可以在很多页面中看到如下警报：
很多运营对 https 没有技术概念，在填入的数据中不免出现 http 的资源，体系庞大，出现疏忽和漏洞也是不可避免的。
好在 W3C 工作组考虑到了我们升级 HTTPS 的艰难，在 2015 年 4 月份就出了一个?Upgrade Insecure Requests?的草案，他的作用就是让浏览器自动升级请求。
在我们服务器的响应头中加入：
header("Content-Security-Policy: upgrade-insecure-requests");我们的页面是 https 的，而这个页面中包含了大量的 http 资源（图片、iframe等），页面一旦发现存在上述响应头，会在加载 http 资源时自动替换成 https 请求。可以查看 google 提供的一个?demo：
不过让人不解的是，这个资源发出了两次请求，猜测是浏览器实现的 bug：
当然，如果我们不方便在服务器/Nginx 上操作，也可以在页面中加入?meta?头：
<meta http-equiv="Content-Security-Policy" content="upgrade-insecure-requests">目前支持这个设置的还只有 chrome 43.0，不过我相信，CSP 将成为未来 web 前端安全大力关注和使用的内容。而?upgrade-insecure-requests?草案也会很快进入 RFC 模式。
从 W3C 工作组给出的?example，可以看出，这个设置不会对外域的 a 链接做处理，所以可以放心使用。
?
想要实时关注更多干货好文，扫描下图关注：
