JS获取上一访问页面URL地址document.referrer实践2

1、JS获取前一个访问页面的URL地址document.referrer

要获取前一个访问页面的URL地址先后端语言均可以，例如PHP的是$_SERVER['HTTP_REFERER']，JavaScript的就是document.referrer。

咱们日常开发，虽然和URL打交道也算比较频繁，可是，彷佛不多使用document.referrer。我起初觉得是兼容性很差，后来测试发现ie7都支持，那就奇怪了，为什么document.referrer用的很少呢？

我想了一下，可能有下面几个缘由：

1. 后端小伙伴帮咱们搞定了相关需求；
2. 只有一些访问数据统计脚本才很是在乎上一个访问页面的url地址是什么；
3. 若是咱们但愿实现的功能是返回上一页，可使用history.go(-1)或者history.back()，咱们并不须要知道上一个访问页面具体的地址是什么。

综合以上几点，致使平时开发不多使用document.referrer。

可是最近作了一个移动端项目，是我第一次在正式项目中使用document.referrer，这里跟你们分享一下相关的实践。

场景是这样的，移动端不管是原生app仍是传统的网页，返回上页是一个比较强烈的需求，以下截图所示：

几乎全部的内页都有这么一个返回上一页的按钮，例如这个页面（点击体验）。

此返回上一页相关HTML代码以下：

<a href="javascript:history.go(-1)" class="header-back jsBack">返回</a>

在大部分场景下，上面办法能够知足咱们的交互需求，可是，在有些时候，上面的代码就有些心有力而气不足，由于当前页面的referrer并不老是存在的。

比方说用户是经过微信分享进来的，直接进入了内页，此时是没有上一页的，返回按钮再怎么点击都没有任何反应，就会让用户很奇怪，十有八九会认为是实现了bug，则会让用户对产品的品质抱有疑虑，那问题可就大了。

怎么办呢！后来我想了一招，那就是若是发现浏览器没有上一页来源信息，咱们就把返回按钮的连接改为首页的连接地址，这样不管何时，用户点击返回按钮必定是会有反应的，而且返回首页从逻辑上讲也是合情合理的。而这里判断是否有没有来源信息就是使用这里的document.referrer，当浏览器得不到上一页的来源信息的时候，document.referrer的返回值就是空字符串''，因而乎，就有相似下面的代码：

if (document.referrer === '') {
    // 没有来源页面信息的时候，改为首页URL地址
    $('.jsBack').attr('href', '/');
}

因而乎，返回按钮的逻辑就完美无缺了。

2、哪些场景下没法得到上一页referrer信息

1. 直接在浏览器地址栏中输入地址；
2. 使用location.reload()刷新（location.href或者location.replace()刷新有信息）；
3. 在微信对话框中，点击连接进入微信自身的浏览器；
4. 扫码进入QQ或者微信的浏览器；
5. 直接新窗口打开一个页面； 2017.8.3更新 新版本Chrome测试，新窗口页面依然有document.referrer
6. 从https的网站直接进入一个http协议的网站（Chrome下亲测）；
7. a标签设置rel="noreferrer"（兼容IE7+）；
8. meta标签来控制不让浏览器发送referer；

   例如：

   <meta content="never" name="referrer">

   兼容性以下图：
   

   iOS浏览器目前仍是使用的老版本的规范值，包括：never, always, origin, default。对于Android浏览器，5.0版本开始支持。基本上，在移动端，使用meta标签来控制referer信息的发送与否已经能够在实际项目中使用了。

9. 等等。

有人可能迫切想知道如何让从https的网站直接进入一个http协议的网站也有document.referrer信息，这方面并非我擅长的地方，因此我也不清楚应该如何解决此问题，或许须要服务器配置那边配合点什么。

更新于翌日
下面是小新同行的真知灼见：

HTTPS turns off HTTP Referrers to HTTP websites. (默认是关闭的，安全缘由。)
开启的话在meta里设置，可能如今的流行的最新版浏览器兼容会好点！
参考：

http://smerity.com/articles/2013/where_did_all_the_http_referrers_go.html

官方这么说的：

https://www.w3.org/Protocols/rfc2616/rfc2616-sec15.html#sec15.1.3