我们有一个应用程序,它使用Request.Browser.MajorVersion
作为缓存键的一部分。我们面临的挑战是确定哪些缓存密钥用于一组历史请求。为此,我们要分析IIS日志,因此需要确定每个请求的ASP.NET Request.Browser.MajorVersion
的值。是否可以单独从用户代理字符串派生出来?
更新
我原先假设Request.Browser.MajorVersion
的值是直接从用户代理字符串获取的版本。但是,在调试会话中确认这个理论我看到了:
我本来期望Request.Browser.MajorVersion
是61,而不是44.任何人都可以提供任何有关这些价值观不同的见解,以及我如何能够自信地说明Request.Browser.MajorVersion
的价值是什么对于给定的用户代理字符串?
更新2
我发现ASP.NET使用一组模板来构建HttpBrowserCapabilities
对象集Request.Browser
。这些可以在这里找到:
%SYSTEMROOT%\ Microsoft.NET \框架[版] \配置\浏览器
查看模板,他们都使用正则表达式来解析用户代理字符串(我已经粘贴了下面的chrome.browser的内容),这表明Request.Browser.MajorVersion
应该与用户代理字符串中的值对应。所以仍然不知道为什么我的本地应用程序返回44作为该值。
<browsers>
<!-- Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/530.1 (KHTML, like Gecko) Chrome/2.0.168.0 Safari/530.1 -->
<browser id="Chrome" parentID="WebKit">
<identification>
<userAgent match="Chrome/(?'version'(?'major'\d+)(\.(?'minor'\d+)?)\w*)" />
</identification>
<capabilities>
<capability name="browser" value="Chrome" />
<capability name="majorversion" value="${major}" />
<capability name="minorversion" value="${minor}" />
<capability name="type" value="Chrome${major}" />
<capability name="version" value="${version}" />
<capability name="ecmascriptversion" value="3.0" />
<capability name="javascript" value="true" />
<capability name="javascriptversion" value="1.7" />
<capability name="w3cdomversion" value="1.0" />
<capability name="supportsAccesskeyAttribute" value="true" />
<capability name="tagwriter" value="System.Web.UI.HtmlTextWriter" />
<capability name="cookies" value="true" />
<capability name="frames" value="true" />
<capability name="javaapplets" value="true" />
<capability name="supportsCallback" value="true" />
<capability name="supportsDivNoWrap" value="false" />
<capability name="supportsFileUpload" value="true" />
<capability name="supportsMaintainScrollPositionOnPostback" value="true" />
<capability name="supportsMultilineTextBoxDisplay" value="true" />
<capability name="supportsXmlHttp" value="true" />
<capability name="tables" value="true" />
</capabilities>
</browser>
</browsers>
更新3
我终于到底了。事实证明,我正在调试的应用程序使用名为51 Degrees的第三方服务,该服务拦截请求并应用自己的请求标头解析,在这种情况下使用本地安装在应用程序服务器上的数据库。这个数据库已经过时,因此对于最近的浏览器版本产生了奇怪的结果。我在上面的Update 2中的详细信息对于vanilla ASP.NET应用程序是有效的,但这确实解释了为什么我的结果与vanilla测试环境不同。感谢所有不遗余力帮助我调查此事的人。
答案 0 :(得分:1)
非常具有挑战性。
此页面将告诉您代理字符串:
http://www.useragentstring.com/
此页面将显示大多数浏览器的代理字符串 http://www.useragentstring.com/pages/useragentstring.php
某些浏览器在代理字符串中有主要/次要版本。有些人没有。浏览器之间甚至浏览器版本之间的格式各不相同,因此即使您知道代理字符串中存在主要版本,解析它仍然可以特定于每个浏览器/版本。
如果您真的需要这样做,那么您最好找一个保持最新且维护良好的图书馆。