Php 未设置HTTP_用户_代理-是否正常？或者可能是机器人？
我想问你关于这件事的机会/经历。Php 未设置HTTP_用户_代理-是否正常？或者可能是机器人？,php,user-agent,Php,User Agent,我想问你关于这件事的机会/经历。 我们的CMS正在从HTTP_用户_代理字符串获取信息。最近，我们在代码中发现了一个bug——忘记检查HTTP_USER_代理是否存在（这是可能的，但老实说：我们只是跳过了，没料到会发生这种情况）——这些情况导致了一个错误。因此，我们已经更正了它，并在那里安装了一个跟踪：如果未设置HTTP_USER_代理，将向我们的跟踪系统发送警报。 现在我们从许多网站获得了过去几个月的数据/统计数据。现在我们的统计数据显示这是非常罕见的0.05-0.1% 另一个有趣的观察
我们的CMS正在从HTTP_用户_代理字符串获取信息。最近，我们在代码中发现了一个bug——忘记检查HTTP_USER_代理是否存在（这是可能的，但老实说：我们只是跳过了，没料到会发生这种情况）——这些情况导致了一个错误。因此，我们已经更正了它，并在那里安装了一个跟踪：如果未设置HTTP_USER_代理，将向我们的跟踪系统发送警报。
现在我们从许多网站获得了过去几个月的数据/统计数据。现在我们的统计数据显示这是非常罕见的0.05-0.1%
另一个有趣的观察：这些请求是单个的。未发现此“用户”在同一会话中有多个页面浏览的情况…
这迫使我们思考。。。我们是否应该将这些请求视为机器人？把他们挡在外面。。。否则这将是一个严重的错误？
谷歌机器人和其他“好机器人”总是发送HTTP_用户_代理信息。
我知道防火墙或代理服务器可能会更改（或删除）此用户代理信息。但根据我们的统计数据，我无法澄清这一点……
你的经历是什么？这里还有其他人对这个话题做过研究吗？
我在stackoverflow上发现的其他帖子只是接受了一个事实：“可能没有发送此信息”。但是我们为什么不马上问呢？<强>这真的是正常的吗？ < P>我会考虑真正的用户缺少用户代理异常，但是它仍然是由防火墙、代理或隐私软件剥离用户代理引起的[极少数]可能性。 缺少用户代理的请求很可能是机器人或脚本（不一定是搜索引擎爬虫）。当然，虽然你不能肯定 可能指示机器人程序/脚本的其他因素：
- 仅请求页面本身，无法请求页面上的资源，如图像、CSS和Javascript
- 来自页面的请求之间非常短的时间间隔（例如在同一秒内）
- 未能在应设置cookie的后续请求中发送cookie或会话ID，但请记住，真正的用户可能禁用了cookie
最好的方法可能是将所有可能性结合起来。：-）
如果这是第一个（在会话中-已经足够了）传入请求，我们可以根据多个标准立即检查请求。在服务器端，我们（可能）有一个动态数据库（根据用户代理信息字符串/IP地址构建），我们可以通过镜像公共数据库来创建这个数据库。（是的，互联网上有几个定期更新的公共数据库可用于检查机器人。它们不仅包含用户代理字符串，还包含源IP）
如果我们成功了，我们可以使用数据库快速检查它。如果该过滤器显示“OK”，我们可以将其标记为受信任的bot并提供请求。
如果请求中没有可用的用户代理信息，我们会遇到问题。。。（实际上这就是我问题的来源）。如果没有用户代理信息，该怎么办？：-）
我们需要在这里做出决定。
简单地拒绝这些请求——考虑这种异常。当然，从这一点上讲，我们可能会失去真正的用户。但是根据我们的统计数据，我认为这不是一个很大的风险。也可以发送回一条可读的消息“抱歉，但您的浏览器不发送用户代理信息，因此您的请求被拒绝”——或其他任何消息。如果这是一个机器人，那么无论如何也没有人读它。如果这是一个人形机器人，我们可以给她/他一些有用的指示。
如果我们决定不拒绝这些请求，我们可以在这里启动MrCode建议的post跟踪机制。好的，我们提供了这个请求，但尝试开始收集行为信息。怎么用？例如，注意db中的IP地址（greylist that），并在响应中传回一个假CSS文件——该文件不是由Web服务器静态提供的，而是我们的服务器端语言：PHP、Java或我们正在使用的任何语言。如果这是一个机器人，它不太可能尝试下载CSS文件。。。如果这是一个真正的浏览器，它肯定会这样做-可能在很短的时间内（例如1-2秒）。我们可以很容易地继续处理提供假CSS文件的操作。只需在greylist数据库中进行IP查找，如果我们判断行为正常，我们可能会将该IP地址列为白名单（例如..）
如果我们再次收到来自灰色列表IP地址的请求
a） 在1-2秒的时间范围内：我们可能会将响应延迟几秒钟（等待并行线程，可能它会同时下载假CSS…），并定期检查我们的greylist数据库，查看IP地址是否消失
b） 在1-2秒的时间范围内：我们只是拒绝响应
所以，像这样的事情。。。听起来怎么样？
但这还不完美。因为在这个机制中，我们为潜在的机器人提供了一个真实的页面。。。我认为我们也可以避免这种情况。对于第一个请求，我们可能会发回一个空的、稍微延迟的重定向页面。。。这可以通过HTML头部分轻松完成。或者wwe也可以使用Javascript，这是一个伟大的机器人过滤器再次。。。但也可能是关闭Javascript的真实用户过滤器（我必须说，如果我有一个没有用户代理字符串的访问者，并且关闭了Javascript，那真的会下地狱……）当然，我们可以在页面上添加一些文本“你很快就会被重定向”或其他东西来安抚潜在的真实用户。当此页面等待重定向发生时，一个真正的浏览器将下载假CSS-因此在重定向发生时IP将被列入白名单，瞧，您的CMS不需要关心用户代理。为什么不需要呢