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

问题描述

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

We have an application which uses Request.Browser.MajorVersion as part of a cache key. We have a challenge to determine which cache key was used for a set of historic requests. To do this we're analysing IIS logs so need to determine what the value would have been for ASP.NET's Request.Browser.MajorVersion for each request. Is it possible to derive this from the user agent string alone?

更新

我最初假定Request.Browser.MajorVersion的值将是直接从用户代理字符串获取的版本.但是，在确认该理论的调试会话中，我看到了这一点:

I originally assumed the value of Request.Browser.MajorVersion would be the version taken direct from the user agent string. However, in a debug session to confirm this theory I see this:

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

I would have expected Request.Browser.MajorVersion to be 61, not 44. Can anyone provide any insight into why these values differ, and how I might be able to confidently tell what the value of Request.Browser.MajorVersion would be for a given user agent string?

更新2

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

I have discovered that ASP.NET uses a set of templates to build the HttpBrowserCapabilities object set as Request.Browser. These are available here:

查看模板，它们都使用regex来解析用户代理字符串(我在下面粘贴了chrome.browser的内容)，这表明Request.Browser.MajorVersion 应该与该值相对应在用户代理字符串中.因此，仍然不知道为什么我的本地应用程序返回44作为该值.

Looking at the templates, they all use regex to parse the user agent string (I've pasted the contents of chrome.browser below), which suggests that Request.Browser.MajorVersion should correspond with the value in the user agent string. So still no idea why my local application is returning 44 as that value.

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

I have finally got to the bottom of this. It turns out that the application I was debugging was using a third-party service called 51 Degrees which intercepts the request and applies its own parsing of the request header, in this case using a database installed locally on the application server. This database had become out of date and was therefore producing strange results for nmore recent browser versions. My details in Update 2 above are valid for vanilla ASP.NET applications, but this does explain why my results were diverging from a vanilla test environment. Thanks to everyone who spared the time to help me investigate this.

推荐答案

非常具有挑战性.

此页面将告诉您您的座席字符串:

This page will tell you your agent string:

http://www.useragentstring.com/

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

This page will show you agent string for most browsershttp://www.useragentstring.com/pages/useragentstring.php

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

Some browsers have a major/minor version in the agent string. Some do not. The format various between browser and even between browser version, so even if you know the major version exists in the agent string, parsing it out can still be specific to each browser/version.

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

If you really need to do this, you're better off finding a library that is kept up to date and well maintained.

这篇关于在ASP.NET中是否可以仅从HTTP请求的用户代理字符串派生浏览器MajorVersion?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！