HTTP Referer并不总是被传递

| 我有一个记录用户访问的应用程序。这些访问均无法直接访问,这些访问中有100%是从另一个站点引荐的。 我正在将“ 0”传递给数据库。大约35%的登录主菜单通过了引荐来源网址,其余为空白。 是否有一个原因?     
已邀请:
如果用户直接访问您的网站,则没有引荐来源。他们也可能进行了设置,因此他们的浏览器从不发送引荐来源。 根据此答案,浏览器在执行元刷新时不一定发送引荐来源网址。     
ѭ1可能为空白的原因有多种。 您必须了解它是浏览器提供的环境变量。意味着用户可以删除它,甚至可以更改它。 从书签,历史记录或通过手动键入链接访问链接的用户没有引荐来源。 众所周知,在围绕javascript的情况下,IE会删除引用。例如
window.open
window.location
,甚至在锚点或ѭ5anchor中设置
target=\"_blank\"
。 单击聊天应用程序中的嵌入式链接(PDF / Word / Excel文档)也不会设置引荐来源。 使用AJAX,J6ѭ,
fopen
和其他语言的其他类似功能可能不会设置引荐请求。 具有类似浏览器组件的cURL,fsockopen,应用程序可能未设置引用。 可能会有更多情况发生,如果我能想到任何合理的信息,我会进行更新。     
浏览器有时会在请求中包含ѭ8。但这不是强制性的(“ 8”是100%自愿的)。实际上,“ 8”周围存在各种隐私和安全问题(例如,如果HTTPS站点将您引荐到HTTP站点,则浏览器不应将引荐网站包含为“ 8”)。所以不要依赖它。     
在Internet Explorer 4.0和更高版本中从一个文档链接到另一个文档时,当链接是从HTTPS页面到非HTTPS页面时,将不会发送Referer标头。当链接从非HTTP(S)协议(例如file://)到另一个页面时,Referer标头也不会发送。有关更多信息,请转到此链接     
直接访问您的页面(在地址栏中键入URL或从书签,历史记录等中键入URL) 浏览器设置(禁用引荐来源网址或为空) 如果有人使用file_get_contents()函数请求页面内容...     
当您停滞不前寻找丢失原因时,这很常见: -有时您的引荐来源网址为https,而您位于http上,它将丢失。 除此以外: -用户通过直接输入网址进行访问。 -用户已添加书签,并且来自书签。 -有时用户会保留浏览器的默认网址(类似于书签) -代理浏览可能会删除引荐来源网址。 -以漫游器的身份访问网站(搜索引擎)     

要回复问题请先登录注册