Questions tagged «user-agent»

一个HTTP标头字段,用于标识浏览器和操作系统。

4
Yahoo Search现在与Bing Search相同吗?
过去,雅虎的(令人难以置信的)糟糕的蜘蛛存在一些严重的问题,结果我们将其阻止了。Tumblr的Marco Arment也于2009年8月31日与我们分享了他的挫败感,这是我们阻止他们的一个因素。 自美国东部时间上午5:30以来,[Yahoo的Spider]每秒向我们发送70-200个请求。我从未见过像这样的东西,即使从过去滥用我们的流氓“实验”爬虫身上也看不到。Robots.txt禁令还不够:我必须在负载平衡器级别通过IP阻止它们。由于他们过去滥用堆栈溢出,因此我想您可能想知道。 雅虎的网络搜索似乎是“由Bing提供支持!” 现在。这很好,因为我们从未遇到过Bing的蜘蛛(又名MSNBOT)问题。 那么,Yahoo的搜索现在是否与Bing搜索相同,还是我们应该考虑潜在地解除对它们的阻止,如果它们以某种方式在各种困难下停止了如此艰难的吮吸?

3
我应该设置什么用户代理?
有Ask机器人,它设置以下标头: Mozilla/2.0 (compatible; Ask Jeeves/Teoma) 考虑到这一点,我有以下问题: 如果我正在编写一个名为Goofy的Web爬网程序,应该使用哪个用户代理? 如果我放Mozilla/2.0或,有Mozilla/5.0什么区别? 我们对我应如何格式化用户代理以符合当前标准的任何其他建议都受到欢迎。

2
我应该阻止我的网站中的漫游器,为什么?
我的日志充满了机器人访问者,通常来自东欧和中国。僵尸程序被标识为Ahrefs,Seznam,LSSRocketCrawler,Yandex,Sogou等。我应该从我的网站阻止这些机器人,为什么? 哪些网站具有增加我的网站访问量的合法目的?其中许多是SEO。 我不得不说,我看不太流量,如果因为机器人任何大量已经抵达。 阻止它们并不难,因为它们都在用户代理中承认它们是机器人。

4
空的用户代理解释
我应该如何解释一个空的用户代理?我有一些自定义分析代码,该代码只能分析人员流量。我有一份工作人员清单,其中列出了人流量和漫游器流量,但是空的User-agent被证明是有问题的。空的用户代理使我获得了大量流量,大约10%。 此外,我还通过分析当前日志来设计人员流量与机器人流量用户代理列表。因此,我可能在那里缺少很多条目。是否存在维护良好的表示机器人流量的用户代理列表,或者相反,是表示人员流量的用户代理列表?

1
在robots.txt中合并用户代理
可以将用户代理一起列出,然后在robots.txt中列出其通用规则吗? User-agent: Googlebot User-agent: ia_archiver #Alexa User-agent: BingPreview #Microsoft User-agent: bingbot #Microsoft User-agent: MSNBot #Microsoft User-agent: Slurp #Yahoo User-agent: Ask Jeeves/Teoma #Ask Disallow: /adm30_buds/

3
任何常规浏览器中的用户代理都包含“机器人”或“抓取”吗?
任何常规浏览器中的用户代理都包含“机器人”或“抓取”吗? 我在我的网站上检查了用户代理,以查看它是否来自机器人。如果是这样,我可以做一些小的优化,因为它们没有登录。(我完全不更改内容) 在为30-40个以上的漫游器添加检查之后,我已经厌倦了添加它们。所以我想知道是否检查它是否仅包含“ bot”或“ crawl”。我知道不会得到所有的机器人,但是会得到很多。但是,如果这可能导致任何误报,则将完全破坏添加到购物车,下订单和登录的功能。
11 user-agent 

3
用户代理标识是否用于某些脚本攻击技术?
我网站上的Apache访问日志条目通常是这样的: 207.46.13.174--[31 / Oct / 2016:10:18:55 +0100]“ GET / contact HTTP / 1.1” 200 256“-”“ Mozilla / 5.0(兼容; bingbot / 2.0; + http:// www .bing.com / bingbot.htm)“ 0.607小姐10.10.36.125:104 0.607 因此您可以在此处看到“用户代理”字段。但是今天我也发现user-agent字段的用法如下: 62.210.162.42--[31 / Oct / 2016:11:24:19 +0100]“ GET / HTTP / 1.1” 200399“-”“} __ test | O:21:” JDatabaseDriverMysqli“:3:{s:2 :“ fc”; O:17:“ …

2
用户代理中URL前面的加号
我运行了一个小型Web搜寻器,必须决定要使用哪个用户代理。 搜寻器代理以及Wikipedia的列表建议采用以下格式: examplebot/1.2 (+http://www.example.com/bot.html) 但是,某些漫游器会省略URL前面的加号。我首先想知道这是什么意思,但找不到任何解释。 RFC 2616认为括号中的所有内容均为注释,并且不限制其格式。但是,对于浏览器来说,在注释中使用分号分隔的标记列表是很常见的,这些标记可以宣传浏览器的版本和功能。除了大多数浏览器以类似的方式格式化外,我认为这没有任何标准化的方法。而且我在评论中找不到任何有关URL的信息。 我的问题是:为什么加号?我需要吗?

3
应对机器人行为异常的策略
我有一个网站,出于监管原因,可能不会自动建立索引或搜索。这意味着我们需要让所有机器人远离,并防止它们爬行该站点。 显然,我们有一个robots.txt文件,从一开始就不允许这样做。但是,观察robots.txt文件只是行为良好的机器人所能做的。最近,我们遇到了行为不佳的机器人的一些问题。我已经将Apache配置为禁止一些用户代理,但是解决这个问题很容易。 因此,问题是,是否有某种方法可以配置Apache(也许通过安装某个模块?)来检测类似机器人的行为并做出响应?还有其他想法吗? 目前,我所能做的就是基于对日志的手动检查来禁止IP地址,这根本不是可行的长期策略。

4
用户代理与base64编码的组件?
(底部的赏金问题) 客户端访问我们的网站时遇到问题,根本原因是WAF(Web应用程序防火墙)不喜欢其User-Agent字符串: User-Agent: Mozilla/5.0 (X11; Linux i686; rv:34.0; C7QcSBPWTsrpX5YLvVZMqiujEZLWPtOYk3tDZ9WhW18=) Gecko/20100101 Firefox/34.0 在这种情况下,base64编码的字符串会触发WAF中的误报,认为用户代理是libwww-perl。base64字符串不会解码为任何可读文本。 用户代理内部是否包含base64编码的字符串,这是正常的还是异常的? 任何RFC或主要供应商惯例是否涵盖了在User-Agent中使用base64字符串? 我试图了解这里发生的事情;我不认为WAF签名与对象完全不符,所以我宁愿不只是禁用它,而且之前我还没有看过这种User-Agent字符串,所以我宁愿更好地理解它的通用性和/或使此用例合法。 该网站是专为人类使用浏览器而设计的-它不是API或类似的东西-并向我报告说,该用户尝试使用“ FF / IE / Chrome”访问该网站,但失败了。但是,我确实显示了来自同一客户端IP与Opera用户代理的成功连接: User-Agent: Opera/9.80 (X11; Linux i686) Presto/2.12.388 Version/12.16 用户报告曾尝试使用IE,但我看到的所有User-Agent字符串似乎都是Linux,这有点奇怪。(与往常一样,与最终用户的联系是通过多方协调的,因此我无法完全相信听到的任何声音)。IP也很可能是业务类Web代理的出站端,这可以解释为什么我看到某些Opera在为某人工作而其他人报告了同一IP的问题。 更新资料 受@PlanetScaleNetworks示例的启发,我搜索了字符串,然后从那里使用UA Tracker搜索base64字符串(或被填充的子集-我搜索了“ =)”)。它返回了大约20个用户代理: 我将为这个问题增加赏金,我正在寻找的答案空间是“哪种软件将base64字符串放入User-Agent中,为什么?这种做法是否合法? ” 次要点: 用户通过使用浏览器插件修改其User-Agent来解决我们的问题,所以这现在是一个学术问题-但我认为这是一个有趣的学术问题:)

4
手机检测(品牌,型号,浏览器等)
您使用什么来检测访客的手机,如果可能的话,该模型会被检测到吗? 目前,我们维护自己的数据库,但是由于缺乏维护它的能力,它确实落后了,因此我们决定尝试使用第三方解决方案。 这些是我的候选人,但我没有时间去尝试所有的东西: DeviceAtlas - 1年个人评估,但基本许可价格可承受。他们的数据库看起来很可靠,可以每日更新,也可以由用户提供测试/更新。我现在很喜欢这个。 DetectRight-一位同事向我推荐了此方法,但实际上在他们的网站上找不到很多。2万个设备-真的吗? WURFL-从UAProf协同衍生的开源数据库。因此,基本上,如果您要使用UAProf解决方案,那么使用WURFL更好。 DetectMoBileBrowsers-这看起来是最简单的。太糟糕了,它取决于语言(PHP)。 请分享您的经验或建议!

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.