c# - 在ASP.NET中是否可以仅从HTTP请求的用户代理字符串派生浏览器MajorVersion？

我们有一个使用Request.Browser.MajorVersion作为缓存键一部分的应用程序。要确定一组历史请求使用了哪个缓存键，我们面临着挑战。为此，我们正在分析IIS日志，因此需要确定每个请求的ASP.NET的Request.Browser.MajorVersion值将是多少。是否可以仅从用户代理字符串派生它？

更新

我最初假设Request.Browser.MajorVersion的值是直接从用户代理字符串获取的版本。但是，在确认此理论的调试 session 中，我看到以下内容:



我本来希望Request.Browser.MajorVersion是61，而不是44。任何人都可以提供这些值为何不同的见解，以及我如何能够自信地确定给定的用户代理字符串Request.Browser.MajorVersion的值是什么？

更新2

我发现ASP.NET使用一组模板来构 build 置为HttpBrowserCapabilities的Request.Browser对象。这些在这里可用:



查看模板，它们都使用regex来解析用户代理字符串(我在下面粘贴了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的第三方服务，该服务拦截请求并对其请求 header 应用其自身的解析，在这种情况下，使用的是本地安装在应用程序服务器上的数据库。该数据库已过时，因此在nmore的最新浏览器版本中产生了奇怪的结果。我在上面的Update 2中的详细信息对原始ASP.NET应用程序有效，但这确实解释了为什么我的结果与原始测试环境有所不同。感谢所有抽出时间来帮助我进行调查的人。

最佳答案

很有挑战性。

该页面将告诉您您的代理字符串:

http://www.useragentstring.com/

此页面将为您显示大多数浏览器的代理字符串
http://www.useragentstring.com/pages/useragentstring.php

某些浏览器的代理字符串中有主/次版本。有些没有。浏览器之间甚至浏览器版本之间的格式都不同，因此，即使您知道代理字符串中存在主要版本，解析出来的格式仍可能特定于每个浏览器/版本。

如果您确实需要这样做，最好选择一个保持最新状态并保持良好状态的库。