我们都知道,当我们的页面请求一个js文件、一个cs文件或者点击到其他页面,浏览器一般都会给这些请求头加上表示来源的Referrer字段.
Referrer在分析用户的来源时非常有用,比如大家熟悉的百度统计里面就利用到Referrer信息了.
但是遗憾的是,目前百度统计仅仅支持来源于http页面的referrer头信息;也就是说,如果你网站是http的,那么百度统计只能统计到从其他http页面进入到你网站的referrer,而如果是从https页面进入到你的网站,百度统计目前是无法统计到.
在介绍解决办法之前,我们先来了解ReferrerPolicies.
ReferrerPolicies如果想及时了解Spark、Hadoop或者Hbase相关的文章,欢迎关注微信公共帐号:iteblog_hadoop目前存在九种ReferrerPolicies,包括:空字符串、no-referrer,no-referrer-when-downgrade,same-origin,origin,strict-origin,origin-when-cross-origin,strict-origin-when-cross-origin以及unsafe-url:enumReferrerPolicy{"","no-referrer","no-referrer-when-downgrade","same-origin","origin","strict-origin","origin-when-cross-origin","strict-origin-when-cross-origin",1/5"unsafe-url"};我们这对每种ReferrerPolicies进行介绍.
空字符串空字符串表示没有referrer策略.
比如我们有一个HTML标签元素,而且并没有声明任何的ReferrerPolicies,这时候的ReferrerPolicies就是空字符串.
默认的空字符串ReferrerPolicies就等同于no-referrer-when-downgrade.
no-referrer最简单的ReferrerPolicies就是no-referrer;这种ReferrerPolicies会导致所有的请求都不带referrer信息.
比如如果https://www.
iteblog.
com/archives/1929页面将ReferrerPolicies设置成no-referrer,那么从这个页面转到https://www.
iteblog.
com/(或者其他任何页面)都不会发送Referer头信息.
no-referrer-when-downgrade这种策略在从受TLS保护的URL跳转到任何潜在可信的URL以及从不受TLS保护的URL(比如HTTP)跳转到任何URL都会发送完整的URLReferrer信息.
但是如果从受TLS保护的URL(比如HTTPS)跳转不受信任的URL(比如HTTP),那么Referrer头将不会带任何的信息.
这是大多数浏览器默认的ReferrerPolicies.
比如:假设https://www.
iteblog.
com/archives/1929页面的ReferrerPolicies设置成no-referrer-when-downgrade,那么从这个页面跳转到任何的https页面将会带上值为https://www.
iteblog.
com/archives/1929的Referer头信息;但是如果从那个页面跳转到任何HTTP页面,将不会带上任何的Referer头信息.
这就是为什么百度统计无法获取到从HTTPS跳转到HTTP的信息.
same-origin对于同源的链接,会发送referrer,其他的不会.
同源意味着域名需要相同,iteblog.
com和idea.
iteblog.
com是非同源的.
origin2/5这种ReferrerPolicies对于任何资源(包括可信和不可信)来说只发送网站的根域名,不发送完整的url.
比如:https://www.
iteblog.
com/archives/1929页面的ReferrerPolicies设置成origin,那么从这个页面跳转到任何网站将会带上值为https://www.
iteblog.
com/的Referer头信息.
strict-origin我们可以把他看做是origin和no-referrer-when-downgrade的结合体.
也就是说,如果从受TLS保护的URL跳转到任何潜在可信的URL以及从不受TLS保护的URL(比如HTTP)跳转到任何URL都会发送根域名的Referrer头信息.
但是如果从受TLS保护的URL(比如HTTPS)跳转不受信任的URL(比如HTTP),那么Referrer头将不会带任何的信息.
比如https://www.
iteblog.
com/archives/1929页面的ReferrerPolicies设置成strict-origin,那么从它跳转到https://xxx.
iteblog.
com将会带上值为https://www.
iteblog.
com/的Referer头信息;如果从那个页面跳转到http://idea.
iteblog.
com将不会带上任何的Referer头信息.
再比如:http://idea.
iteblog.
com页面的ReferrerPolicies设置成strict-origin,那么从这个页面跳转到http://books.
iteblog.
com或者https://www.
iteblog.
com/archives/1929将会带上值为http://idea.
iteblog.
com/的Referer头信息.
不过目前这种ReferrerPolicies浏览器可能不支持.
origin-when-cross-origin该策略在同源的链接中发送完整的URL,其他情况仅发送根域名.
需要注意的是https://www.
iteblog.
com和被认为是非同源的.
比如https://www.
iteblog.
com/archives/1929页面的ReferrerPolicies设置成origin-when-cross-origin,那么从它跳转到https://www.
iteblog.
com/archives/1464将会带上值为https://www.
iteblog.
com/archives/1929的Referer头信息;如果从那个页面跳转到http://idea.
iteblog.
com/页面(注意这里HTTP和HTTPS页面都可以),将会带上值为https://www.
iteblog.
com/的Referer头信息.
不过这种ReferrerPolicies在Chrome实现的时候被误写成了origin-when-crossorigin.
strict-origin-when-cross-origin这种策略可以看做是origin-when-cross-origin和no-referrer-when-downgrade的结合体.
对于同源请求,发送完整的URL;对于同为https的页面,或者是从HTTP页面跳转到任何的页面(包括HTTP和HTTPS)只发送根域名;如果是从https页面跳转到http将不发送referrer.
RAKsmart 商家我们应该较多的熟悉的,主营独立服务器和站群服务器业务。从去年开始有陆续的新增多个机房,包含韩国、日本、中国香港等。虽然他们家也有VPS主机,但是好像不是特别的重视,价格上特价的时候也是比较便宜的1.99美元月付(年中活动有促销)。不过他们的重点还是独立服务器,毕竟在这个产业中利润率较大。正如上面的Megalayer商家的美国服务器活动,这个同学有需要独立服务器,这里我一并整理...
LOCVPS发布了7月份促销信息,全场VPS主机8折优惠码,续费同价,同时香港云地/邦联机房带宽免费升级不加价,原来3M升级至6M,2GB内存套餐优惠后每月44元起。这是成立较久的一家国人VPS服务商,提供美国洛杉矶(MC/C3)、和中国香港(邦联、沙田电信、大埔)、日本(东京、大阪)、新加坡、德国和荷兰等机房VPS主机,基于XEN或者KVM虚拟架构,均选择国内访问线路不错的机房,适合建站和远程办...
已经有一段时间没有听到Gigsgigscloud服务商的信息,这不今天看到商家有新增一款国际版线路的美国VPS主机,年付也是比较便宜的只需要26美元。线路上是接入Cogentco、NTT、AN2YIX以及其他亚洲Peering。这款方案的VPS主机默认的配置是1Gbps带宽,比较神奇的需要等待手工人工开通激活,不是立即开通的。我们看看这款服务器在哪里选择看到套餐。内存CPUSSD流量价格购买地址1...