为什么我在看的浏览器功能，当我得到这些奇怪的结果？ [英] Why am I getting these strange results when looking at browser capabilities?

问题描述

我目前正在为浏览器的功能，我试图测试浏览器定义文件来与.NET 4.0。要做到这一点，我在附加使用Firefox的更改用户代理，我有一个简单的网页，其中以下报告：

I am currently looking into browser capabilities and am trying to test the browser definition files that come with .NET 4.0. To do this I am using an add-on for Firefox to change the user agent and I have a simple page which reports on the following:

Request.UserAgent
Request.Browser.Id
Request.Browser.Browser
Request.Browser.MajorVersion
Request.Browser.MinorVersion
Request.Browser.Platform
Request.Browser.IsMobileDevice
Request.Browser.MobileDeviceManufacturer
Request.Browser.MobileDeviceModel

一般来说，这给出了基于在默认浏览器定义文件的注释提供的实施例的正确信息。但是我看到的时候奇怪的结果时间，我不能完全解释的。

Generally this gives the correct information based on the examples provided in the comments in the default browser definition files. However I am seeing strange results from time to time that I cannot quite explain.

您可以在 iphone.browser 定义文件这是例如iPhone用户代理如下：

Take the example iPhone user agent in the iphone.browser definition file which is as follows:

Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko) Version/3.0 Mobile/1A543a Safari/419.3

这应该返回浏览器如Safari，这确实。这是下降到有Safari浏览器作为父母，这对长期匹配的IPhone网关 Safari浏览器。

This should return the browser as Safari, which it does. This is down to the IPhone gateway having Safari as a parent, which matches on the term Safari.

稍微改变用户代理，因此模拟了邮件客户端在iPhone用户代理是指去除用户代理的端部如下：

Altering the user agent slightly so it emulates the user agent of the mail client on an iPhone means removing the end part of the user agent as follows:

Mozilla/5.0 (iPhone; U; CPU like Mac OS X; en) AppleWebKit/420+ (KHTML, like Gecko)

这现在应该返回作为Mozilla的浏览器，因为这将是无法匹配的词 Safari浏览器。然而，在分析此之后的第一个报告回不正确的信息，而且还指示浏览器Safari浏览器将

This now should return Mozilla as the browser, as it will be unable to match on the term Safari. However, analysing this immediately after the first reports back incorrect information, and still indicates the browser to be Safari.

与 App_Browsers文件文件夹中添加自定义 .browser 文件，然后修改，似乎迫使它是正确的暂时，几乎像定义或规则正在高速缓存和每个请求没有得到充分执行。

Adding a custom .browser file with the App_Browsers folder and then modifying that seems to force it to be correct temporarily, almost like the definitions or rules are being cached and not fully run on each request.

这工作的其他方式也一样，如果你的第二个例子用户代理开始，然后在分析第一它会被取代Safari浏览器Mozilla的报告。

This works the other way too, if you start with the second example user agent then upon analysing the first it will report as being Mozilla instead of Safari.

任何人都可以解释这种现象或变通办法解决它？难道是试图做某种（不那么）聪明缓存它使得基于类似的用户代理假设？

Can anyone explain this behaviour or a way to work around it? Is it trying to do some sort of (not so) clever caching where it makes assumptions based on similar user agents?

感谢。

推荐答案

还有更多的比赛不仅仅是寻找字符串野生动物园。如果你看一下通过Mono的ASP使用的用户代理数据库。净实现，你会看到你的第一个更具体的用户代理字符串匹配的更具体的规则之一，而浏览器的版本将被设置。但即使是修剪用户代理字符串仍然命中将其标识为的iPhone的一些变种，也就是后来的presented为野生动物园。

There is more to the match than just looking for the string "Safari". If you look at the user agent database used by Mono's ASP.Net implementation, you'll see that your first more specific user agent string will match one of the more specific rules, and the browser version will be set. But even the trimmed user agent string still hits a rule that identifies it as some variant of "iPhone", which is later presented as "Safari".

微软的ASP.Net最有可能采用了非常类似的数据库，我只是用单作为一个例子，因为code是在网络上现成的。

Microsoft's ASP.Net most likely uses a very similar database, I just used Mono as an example since the code is readily available on the web.

于是，我重新审视我的回答，并实现我彻底misinter preTED的问题！你说得对：缓存是在这里的行动。在.NET Framework试图以节省时间解析用户代理字符串。一旦UA字符串进行分析，其结果保存在一个散列表中。关键是在UA串，截断。

So, I revisited my answer, and realized I completely misinterpreted the question! You are right: caching is in action here. The .NET Framework tries to save time parsing the user-agent strings. Once a UA string is parsed, the result is saved in a hash table. The key is the UA string, truncated.

默认情况下此密钥长度为64个字符，这就是为什么当你改变长期以来UA字符串的结尾你观察到没有变化。此设置是由物业控制 UserAgentCacheKeyLength HttpCapabilitiesDefaultProvider 的。为了验证，我加了

By default this key length is 64 characters, which is why when you change the end of a long UA string you observe no changes. This setting is controlled by the property UserAgentCacheKeyLength of HttpCapabilitiesDefaultProvider. To verify, I added

<browserCaps userAgentCacheKeyLength="512" />

到＆LT;的System.Web＆gt;在Web.config中元素在我的测试项目。有了这个快速解决问题消失。

to the <system.web> element in Web.config in my test project. With this quick fix the problem goes away.

这篇关于为什么我在看的浏览器功能，当我得到这些奇怪的结果？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！