HTTP Referer简单说明

HTTP Referer二三事授权方式:署名,非商业用途,保持一致,转载时请务必以超链接

(http://www.fwolf.com/blog/post/320)的形式标明文章原始出处和作者信息及本声明。
什么是HTTP Referer简言之,HTTP Referer是header的一部分,当浏览器向web服务器发送请求的时候,一般会带上Referer,告诉服务器我是从哪个页面链接过来的,服务器籍此可以获得一些信息用于处理。比如从我主页上链接到一个朋友那里,他的服务器就能够从HTTP Referer中统计出每天有多少用户点击我主页上的链接访问他的网站。
Referer其实应该是英文单词Referrer,不过拼错的人太多了,所以编写标准的人也就将错就错了。
我的问题我刚刚把feed阅读器改变为Gregarius,但他不像我以前用的liferea,访问新浪博客的时候,无法显示其中的图片,提示“此图片仅限于新浪博客用户交流与沟通”,我知道,这就是HTTP Referer导致的。
由于我上网客户端配置的特殊性,首先怀疑是squid的问题,但通过实验排除了,不过同时发现了一个Squid和Tor、Privoxy协同使用的隐私泄露问题,留待以后研究。
Gregarius能处理这个问题么?答案是否定的,因为Gregarius只是负责输出html代码,而对图像的访问是有客户端浏览器向服务器请求的。
不过,安装个firefox扩展也许能解决问题,文中推荐的”Send Referrer”我没有找到,但发现另外一个可用的:”RefControl“,可以根据访问网站的不同,控制使用不同的Referer。
但是我不喜欢用Firefox扩展来解决问题,因为我觉得他效率太低,所以我用更好的方式——Privoxy。
Privoxy真棒在Privoxy的default.action中添加两行:
{+hide-referrer{forge}}.album.sina.com.cn这样Gregarius中新浪博客的图片就出来了吧?+hide-referrer是Privoxy的一个过滤器,设置访问时对HTTP Referer的处理方式,后面的forge代表用访问地址当作Refere的,还可以换成block,代表取消Referer,或者直接把需要用的Referer网址写在这里。
用Privoxy比用Firefox简单的多,赶紧换吧。
From https to http我还发现,从一个https页面上的链接访问到一个非加密的http页面的时候,在http页面上是检查不到HTTP Referer的,比如当我点击自己的https页面下面的w3c xhtml验证图标(网址为http://validator.w3.org/check?uri=referer),从来都无法完成校验,提示:
No Referer header found!原来,在http协议的rfc文档中有定义:
15.1.3 Encoding Sensitive Information in URI's...   Clients SHOULD NOT include a Referer header field in a (non-secure)   HTTP request if the referring page was transferred with a secure   protocol.这样是出于安全的考虑,访问非加密页时,如果来源是加密页,客户端不发送Referer,IE一直都是这样实现的,Firefox浏览器也不例外。但这并不影响从加密页到加密页的访问。
Firefox中关于Referer的设置都在里,有两个键值:

network.http.sendRefererHeader (default=2)
设置Referer的发送方式,0为完全不发送,1为只在点击链接时发送,在访问页面中的图像什么的时候不发送,2为始终发送。参见Privacy Tip #3: Block Referer Headers in Firefox

network.http.sendSecureXSiteReferrer (default=true)
设置从一个加密页访问到另外一个加密页的时候是否发送Referer,true为发送,false为不发送。

利用Referer防止图片盗链虽然Referer并不可靠,但用来防止图片盗链还是足够的,毕竟不是每个人都会修改客户端的配置。实现一般都是通过apache的配置文件,首先设置允许访问的地址,标记下来:
# 只允许来自domain.com的访问,图片可能就放置在domain.com网站的页面上SetEnvIfNoCase Referer "^http://www.domain.com/" local_ref# 直接通过地址访问SetEnvIf Referer "^$" local_ref然后再规定被标记了的访问才被允许:
<FilesMatch ".(gif|jpg)">Order Allow,DenyAllow from env=local_ref</FilesMatch>或者
<Directory /web/images>   Order Deny,Allow   Deny from all   Allow from env=local_ref</Directory>这方面的文章网上很多,参考:

Apache 下防止盗链的解决办法
Apache的环境变量设置
配置 Apache 实现禁止图片盗链
不要使用Rerferer的地方不要把Rerferer用在身份验证或者其他非常重要的检查上,因为Rerferer非常容易在客户端被改变,不管是通过上面介绍的Firefox扩展,或者是Privoxy,甚至是libcurl的调用,所以Rerferer数据非常之不可信。
如果你想限制用户必须从某个入口页面访问的话,与其使用Referer,不如使用session,在入口页面写入session,然后在其他页面检查,如果用户没有访问过入口页面,那么对应的session就不存在,参见这里的讨论。不过和上面说的一样,也不要过于相信这种方式的“验证”结果。
个人感觉现在Rerferer除了用在防盗链,其他用途最多的就是访问统计,比如统计用户都是从哪里的链接

什么是HTTP Referer
  简言之,HTTP Referer是header的一部分,当浏览器向web服务器发送请求的时候,一般会带上Referer,告诉服务器我是从哪个页面链接过来的,服务器籍此可以获得一些信息用于处理。可以用于统计访问本网站的用户来源,也可以用来防止盗链接(注意:用这种方法来防止盗链接有很大的局限性,因为Header中的信息很容易伪造)。在.NET中取得该字段非常简单,你只需要做如下调用即可:Request.UrlReferrer,该值返回的是一个Uri对象。值得注意的是,当你想获取Url字符串的时候,最好不要直接调用Request.UrlReferrer.ToString()方法,因为这样有可能返回的是一堆乱码。产生的原因是,用户在来你网站之前的那个网站的编码方式(Encoding)也许和你的网站不一样,导致Url Decode的时候出现了乱码。这里建议使用Request.UrlReferrer.OriginalString,这个属性返回的就是当时构造Uri对象的原始Url,即没有经过Decode操作。当然,如果你只是想获取Url字符串的话,还可以这样调用:Request.Headers["Referer"]。但你得先判断一下浏览器是否发送了该值,如果没有发送该值,则返回null。(小提示:细心的人可能看出来了,在HTTP Header中Referer的不是英文单词Referrer。Referer其实应该是英文单词Referrer,不过拼错的人太多了,所以编写标准的人也就将错就错了。但在.NET中修改了这个错误,所以是Request.UrlReferrer,而不是Request.UrlReferer,使用的时候小心一点就是了) 
 
  Referer不能正确获取
  Firefox中关于Referer的设置有两个键值:network.http.sendRefererHeader (default=2) 设置Referer的发送方式,0为完全不发送;1为部分发送;2为始终发送。我检查了我的Firefox设置,明明设置的是2啊,也就是说都要发送这个字段的,但我调试的时候发现Firefox确实没有发送这个字段,Request.UrlReferrer始终为null。于是上网去找找有没有解决的办法,发现有很多人和我遇到了相同的问题,但都没有说明原因,也没有找到合适的解决方案。在微软的官方网站,好像有人提交了这个Bug,请参考http://connect.microsoft.com/Vis ... x?FeedbackID=103334。搞了半天,微软回复说没法重现这个Bug。FT。。。除了Firefox外,其他几个浏览器IE,Safari,好像都有这个问题。

  查找解决办法
  在网上找了一阵,还是无果而终。于是我自己观察了网站的访问日志,发现并不是所有的Firefox的访问记录Url Refferrer都是空的,有的确是正确的发送了信息的。我开始还怀疑是FF的版本问题,于是我去下载了FF的最新版本3.0.8,装上之后结果依然。看来不是版本的问题。我仔细想了一下,出现这样的情况无非有两个原因:第一,FF没有正确发送Refferrer到服务器;第二,FF正确发送了Refferrer,服务器的.NET程序没能正确截取该值。为了查看FF是否正确发送了Refferre,我用了一个网络抓包工具,把FF发送的数据抓回来分析了一番,惊奇的发现在FF发送的Header正确的发送了Refferrer。如下所示:
Accept-Charset: gb2312,utf-8;q=0.7,*;q=0.7
Keep-Alive: 300
Connection: keep-alive
Referer: http://www.baidu.com/s?wd=%C3%C0%C3%FB%CC%DA
Cookie: ....

  这样一来,就彻底排除了FF没有正确发送的问题。难道是Server没能正确识别FF发送的Refferrer?我开始还是有点怀疑的,可是仔细一想,除了Refferrer没能正确处理以外,其他的Header都是正确的啊,.NET不会傻到这种程度的,所以我觉得还是客服端在发送数据的时候出了问题。这时候,我突然想到很多防火墙软件会扫描网络数据包。会不会是防火墙截断了FF发送的Refferrer呢?我机器上是OEM的诺顿防火墙,由于一直用诺顿,我对他还是有些好感的。为了验证我的想法,我暂时关闭了诺顿的Internet监控功能。重新试了一遍之前的访问操作,惊奇的发现这次我的访问记录里面正确提取了Refferrer。到这里,我大概就明白了,肯定是诺顿自动去掉了Header中的Refferrer信息!!这个时候,我重新测试了IE,Safari等浏览器,都能正确获取Refferrer值了。到此为止,这个问题算是找到答案了,诺顿去掉了我的浏览器发送的Header中的Refferer信息!!我的问题是解决了,不知道网上其他那些遇到同样问题的朋友是否也是防火墙的原因。希望我的经历对此有些帮助。
  最后,由于我在找原因的过程中,发现有的朋友叙述的问题与我的还不完全一样,他们的是IE能正确提取Refferrer,而FF却不行,这个时候请你看看的FF设置是否有问题,即network.http.sendRefererHeader的值是否设置为2。


阅读更多
个人分类: java
想对作者说点什么? 我来说一句

没有更多推荐了,返回首页

关闭
关闭
关闭