服务器端用户代理检测/嗅探是否不好？

Question

客户端用户代理检测is known to be bad 和discouraged in favor of feature detection。但是，根据传入的 user agent field in a HTTP request做出不同的反应也是不好的吗？

一个例子是根据传入的用户代理是移动还是桌面发送更小或更大的图像。

Answer 1

我认为这取决于你的动机是什么。例如，在移动网络领域，您尝试做的是为用户提供在他们的平台上看起来合理的东西。为什么要关心用户报告的是什么用户代理，而这纯粹是为了他们自己的利益？如果他们试图用不同的用户代理来欺骗你，那么他们是唯一受苦的人。主要的麻烦当然是误报。它并不完全可靠。

我认为您不应依赖它，但移动开发人员正受到此类泛泛声明的攻击。是的，有很多不错的选择，但在您能想象到的所有浏览器中，随着确定性开始下降，这些信息在某些时候实际上是有用的。

您绝对不会使用任何纯文本标题来实现访问控制。

当有更好的替代方案时，用户代理检测被认为是不好的，但将其包含在可以确定优雅降级的检测过程中肯定没有害处。

我在整个过程中遇到的问题是，我们忙于为用户提供一些明智的东西，但似乎从不认为在您不确定时提出问题是可以接受的。如果您不确定用户代理，为什么不询问一次并存储？您可以使用用户代理作为指导。

所以总结一下我的想法，基本上用户代理标头是不可靠的，所以依赖它是不好的。这并不意味着您无法从中提取一定程度的有价值信息，因为更可靠的选择会让您处于不确定状态。一般来说，断定它是坏的是错误的。只是你对这些信息所做的事情决定了它是否变坏。

更新

在看到您对问题的更新后，我有以下 cmets 可以贡献。 我想嗅探图像请求并为客户端提供基于用户代理的图像吗？

如果这是唯一的变量，那么它可能会起作用，但您唯一需要改变的是图像的情况很少见。我不想检测每个请求，因为我想为客户提供一致的解决方案。这意味着我为他们提供了一个页面，使他们请求正确的资源。该页面为所有集成资源提供了一个统一的解决方案。本文档中的所有变体都适用于特定视图。

我尊重用户代理字符串更改中间视图的可能性非常小，似乎不值得担心。然而，采用这一原则也减少了您需要执行浏览器/平台检测的次数，这只会是有益的。这使您可以更轻松地在客户端上切换视图。如果客户说实际上你的观点错了，我是平板电脑而不是手机，你该如何纠正？您为用户提供了一个更好的页面，否则您将需要为您的图像请求欺骗标题......糟糕的想法。 不要使用用户代理字符串来提供图片等通用资源。

潜在的改进

平台识别是网络现代发展中一个非常活跃的领域。随着计算变得越来越普遍，平台变化越来越大，我们对了解我们所服务的平台的需求也在增加。我认为当前条件下这个问题的一般解决方案将落在指纹和统计分析上。

考虑这个应用程序 - akinator.com - 请注意来自大量稀疏数据的统计分析是如何准确得令人讨厌的。在有限的环境（浏览器配置集）中，您可以想象我们可以向客户端的浏览器询问一些问题。然后，我们对某些 n 维特征空间中的响应进行统计分析。使用用户代理作为这个空间的一个维度将是有用的和自我限制的，这取决于你找到的结果。如果它在很大程度上不准确，那么它会看到很大的价差，并且您从中获得的价值量将是自我限制的。

当然，您从该统计模型中获得任何价值的能力要求您能够获得一些经过验证的事实。例如，这可能是运行 JavaScript 测试套件来检测客户端 js 功能，或者实际上，在不确定的情况下，您实际上可以要求用户告诉您他们的平台是什么。

---

如需进一步阅读，请参阅 Mozilla 的这篇文章

https://developer.mozilla.org/en/Browser_detection_using_the_user_agent

今天，寻找这些字符串是知道 设备在提供服务之前在移动设备（或平板电脑）上运行 HTML。

Answer 2

视情况而定。 使用 user agent 作为唯一信号来分支服务器级代码的逻辑充其量是可疑的，在最坏的情况下是不安全的，但它适用于定义死记硬背的功能当提供 vanilla 代理时，特定类别的浏览器和服务内容可以满足他们的需求。

您勾勒出的场景完美地说明了这一点。尝试检测移动浏览器并在服务器级别缩小您发送给他们的内容是完全合适的，因为您正在尝试调整用户体验以更好地满足他们的需求（例如，通过提供更小的图像和更好的内容流以适应较小屏幕的限制），同时平衡它们与服务器的需求（发送较小的图像，从而产生更少的负载和更少的线路带宽）。这个策略只是需要改进。

您应该始终遵循一些设计原则，以确保您的用户代理检测实践不会被您的用户视为可疑：

• 始终提供查看您网站的完整版本并相应地规划您的负载配置文件的能力。否则，您将有人试图通过更换代理来规避这一点。

• 始终在您创建模态视图时明确定义对网站内容的修改。这将清除您可能已或未进行的更改周围的所有FUD。

• 始终提供指向您网站的备用版本的路径。例如，使用 http://mobile.example.org 之类的东西将人们迁移到移动版本，在设计级别假设当请求此路径时，您的受众明确要求了它。

• 奖励用户向您提供正确的代理凭据，从而在内容和性能方面为他们提供更好的体验。当您预测到他们的需求并在他们正在浏览的网站版本上为他们提供更快的性能时，用户会更快乐。

• 避免滥用和手动重定向模式。例如，当您检测到他们正在运行 iOS 时，请不要使用您的移动应用程序的大型弹出式广告来阻止他们。 （诚​​然，这是我的一个小烦恼。）

• 从不在用户代理的基础上限制对网站区域的访问（选择严厉警告用户如果他们偏离轨道并起草您的支持政策将无法正常工作周围）。例如，我们中的许多人都深情地记得为“在 Internet Explorer 中运行最好”的站点更改了我们的代理，以禁止所有其他浏览器。如果可以避免，您不应该再成为这种不良做法的例子。

简而言之：提供正确的用户代理是用户的决定。您可以使用它来为选择运行普通客户端或不知道客户端的用户定义默认体验好点。这里的目标是奖励您的用户，不提供虚假的用户代理，为他们提供他们需要的选项和他们想要的体验，同时平衡他们的需求和您自己的需求。超出此范围的任何事情将导致他们犹豫不决，因此应该被认为是非常可疑的。

您当然可以尝试检测浏览器by other means，但这仍然是一个开放研究领域。浏览器功能和指纹在功能上竞争时会发生变化，目前，试图追赶以优化性能通常是棘手的。

我同意this answer 关于统计分析的使用，所以不要误会我的意思。但是，作为一个在这个领域积极工作的人，我可以告诉你，没有什么灵丹妙药可以给你完美的分类确定性。然而，启发式方法可以并且将帮助您更有效地平衡负载，为此，一旦您明确定义了可接受的错误率，浏览器查询策略就可以并且确实对您有用。

Answer 3

在“标准浏览器”场景中，它还不错，但它不可靠，因为很多浏览器都为用户提供了一些配置选项/插件/任何需要修改的东西用户代理。

在这种情况下，我会实现类似于 facebook 的东西 - 他们基于 UA（可能还有其他东西，也称为“指纹分析”）检测是否重定向到移动版本（即http://m.facebook.com/...） （即http://www.facebook.com...）。同时，他们提供了一个 URL 参数 m2w，它覆盖了这个重定向机制。

根据移动运营商的不同，它们甚至可能会出现一些内容感知代理/缓存，这些代理/缓存可以即时缩放/重新压缩图像，并在您的终端显示为“正常”浏览器...

考虑浏览器之外的场景...例如，如果您使用某些特定协议（如 WebDAV），这可能是具有某种“特定于平台”行为的唯一选择（例如 OS X 之间的差异）和 Windows）。