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?
UPDATE
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:
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?
UPDATE 2
I have discovered that ASP.NET uses a set of templates to build the HttpBrowserCapabilities
object set as Request.Browser
. These are available here:
%SystemRoot%\Microsoft.NET\Framework[version]\Config\Browsers
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>
UPDATE 3
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.