我應該在確定轉介時使用Request.UrlReferrer

我與我的團隊圍繞使用HttpRequest.UrlReferrer進行了一次有趣的討論，並希望徵求來自社區的反饋。根據W3C spec：我應該在確定轉介時使用Request.UrlReferrer

引薦[原文如此]請求頭字段允許客戶端指定，對於服務器的益處，地址的（URI）從中 Request-URI中是資源獲得（該「引薦」，雖然頭字段拼寫錯誤。）引薦請求頭允許服務器產生的反向鏈接列表來資源利益，日誌，優化高速緩存等，還允許過時或錯誤輸入鏈接爲追蹤維修。如果請求URI是從源獲得的，並且沒有自己的URI，例如從用戶鍵盤輸入的用戶鍵盤輸入，則不應發送Referer 字段。

Request.UrlReferrer對象執行將包含格式正確的URI的引用字符串轉換爲每個請求上具有屬性的對象的工作。

根據我們的記錄有一些進來包含在轉診無效數據，如請求：

localhost 
app:/BeamBackTest.swf 
app:/multtiple.swf 
app:/AFriendFeed.swf 
ALToolBar 
app:/index.html 
mhtml:file://C:\Documents+and+Settings\User\Desktop\oracle\What+is+a+View+in+Oracle+-+Stack+Overflow.mht

使用Request.UrlReferrer將意味着上述情況將是NULL。儘管數據可能很有趣，但可能無用，但使用Request.UrlReferrer丟棄基於W3C規範的無效數據還是使用Request.ServerVariables [「HTTP_REFERER」]保留它是更好的方法。

來源

2010-09-09 Geoff Dalgas

那麼，這取決於你在處理數據。如果你正在做的事情需要一個有效的URI，那麼你也可以使用Request.UrlReferrer，因爲你必須去掉它。但是如果你所做的只是記錄它，並且你的日誌記錄工具可以處理奇怪的事情，我會推薦第二種方法 - 尤其是app：/ data，這可能會產生有用的模式。

來源

2010-09-09 05:42:42

它的主觀根據您的需求。即使它是垃圾，我們也會存儲所有內容。有一天，我們可能會知道如何更好地處理它，它不再是垃圾。如果我們沒有存儲它，因爲我們當時不知道它，我們永遠無法拿回來。

來源

2010-09-09 05:42:27

我應該在確定轉介時使用Request.UrlReferrer

回答

相關問題