哪些浏览器/插件会阻止发送 HttpReferer?

发布于 2024-07-08 10:45:04 字数 188 浏览 9 评论 0原文

我正在尝试解释服务器日志中的 HttpReferer 字符串。 似乎有相当多的空值。

我想知道其中有多少空值是由于人们直接在浏览器中输入我们的 URL 造成的,有多少可能是由于某种阻止发送 Referer 的阻止实用程序造成的。

我真的不知道有多少人正在使用可能阻止引用的工具或浏览器或“匿名器”。 有什么意见吗?

I am trying to interpret HttpReferer strings in our server logs. It seems like there is quite a high number of empty values.

I am wondering how many of these empty values are due to direct hits from people entering our URL directly into a browser and how many might be due to some kind of blocking utility that prevents the Referer from being sent.

I really have no idea how many people are using tools or browsers or 'anonymizers' that might block the refer. Any input?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

残龙傲雪 2024-07-15 10:45:04

我个人使用 Firefox 的“Web Developer”扩展禁用它,只是因为一些“有用”的网站突出显示了我用来访问该页面的搜索词。

谢谢,我完全有能力安装荧光笔插件,或搜索页面内的单词。

I personally disable it using "Web Developer" extension of Firefox, only because of some "helpful" sites that highlight the search terms that I used to get to that page.

Thanks, I am fully capable of installing a highlighter plugin, or search for the words inside your page.

铃予 2024-07-15 10:45:04

我认为很大一部分实际上可能是ISP的限制造成的。 我知道我的 ISP(英国电信)将其过滤掉(可能在路由器上),这有时非常烦人。

事实证明,该阻止实际上是由 Zone Alarm(一种通常由 ISP 提供的软件防火墙)实施的。

I think a large proportion may actually be caused by ISPs' restrictions. I know my ISP (BT, in the UK) filters it out (probably at the router) which is bloody annoying at times.

As it turns out, the block is actually put in place by Zone Alarm, a software firewall, which is often supplied by ISPs.

浅语花开 2024-07-15 10:45:04

Opera 在 F12 菜单中有一个快速切换功能,您可以打开“发送推荐人信息”或不发送到您正在浏览的网站。

Opera has a quick toggle in the F12 menu that you can switch on "Send Referrer Information" or not to the site(s) you're surfing around.

双马尾 2024-07-15 10:45:04

我曾经在我的博客应用程序中记录所有这些内容 - 几乎所有机器人都不会发送推荐人信息。

您应该能够做出有根据的猜测,判断是由于它被过滤掉了还是只是因为人们输入了 URL。

如果第一次点击没有引荐来源网址,但加载图像/CSS 等有引荐来源网址信息,那么他们只是直接输入 URL。
如果他们只拉取 HTML,没有图像或 CSS,那么他们很可能是机器人(或者可能使用 Lynx)。
如果他们拉取没有引荐来源网址的 HTML、图像和 CSS,那么这些内容就会被过滤掉。

I used to log all this stuff in my blogging app - pretty much all bots never send referrer info.

You should be able to make an educated guess as to whether it's down to it being filtered out or just people entering the URL.

If the first hit has no referrer but the loading of images/CSS etc has referrer info then they just entered the URL directly.
If they only ever pull down HTML with no images or CSS they are most likely a bot (or using Lynx perhaps).
If they pull down HTML, images and CSS with no referrer then it's being filtered out.

千秋岁 2024-07-15 10:45:04

一些防病毒软件速度较慢,并且出于“安全”原因也开始这样做。

我们有一个电子邮件表单,使用引用跟踪来消除随机机器人垃圾邮件的要点,但有些人抱怨它不起作用。

并不完全美妙,但是引用标头的好处远多于仅仅“让我们作恶,看看人们来自哪里”来使其合法化。

(例如,众所周知,某些防病毒软件包会完全停止电子邮件工作,客户会打电话给您并告诉您这是您的错,直到您告诉他们扔掉他们的垃圾,我以前从未听说过该公司'防病毒软件第 40 次,他们听了,他们的问题神奇地解决了)

关于安全性的附录

引用者跟踪对于保持站点内的状态非常有用。 (无需 cookie)

引荐来源网址跟踪对于确认用户来源来自网站本身(无需 cookie)非常有用,

尽管我认为通过引荐来源网址泄露数据的第三方网站存在合法的隐私问题,并且收件人也看到了这一点。

所以:

3rd-party => site  # referrer preferred blank
local     => local # referrer preferred kept

至少在这里您可以轻松区分来自外部来源的“热链接”和内部链接。

此外,因此,某些浏览器默认会阻止来自 SSL 网站的跨域引用。

Some antivirus software is retarded and also started doing this for "security" reasons.

We had an email form that used referrer tracking to eliminate the gist of the random bot-spam an some people moaned that it didn't work.

Not entirely wonderful, but there are far more good uses of the referrer header than for just 'lets be evil and watch where people came from' to legitimise it.

( Some antivirus packages have been known to stop email working altogether for instance, and the clients will ring you and tell you its your fault until you tell them to get rid of their rubbish i've never heard of that company before' antivirus for the 40th time and they listen and their problem magically resolves )

Addendum on security

Referrer tracking is very useful for keeping state within a site. (Without needing cookies)

Referrer tracking is very useful to acknowledge that a users origin was from the site itself ( without needing cookies )

Though I see a legitimate privacy concern with leaking 3rd party sites leaking data via referrer, and the recipient seeing that.

So:

3rd-party => site  # referrer preferred blank
local     => local # referrer preferred kept

At least here you can easily distinguish between a "hotlink" from an external source and an internal link.

Also, because of this, cross-domain referrals from SSL websites are blocked by default by some browsers.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文