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