ClientTarget and user proxy alias, clienttarget alias

ClientTarget and user proxy alias, clienttarget alias

Add the alias of a specific user proxy to the internal set of the user proxy alias.

From

The set of user proxy aliases indicates that the ASP. NET Server control should be the target user proxy for the content it presents. The information can be obtained in the Page. ClientTarget attribute and is only a string,However, similar attributes cannot be found in MVC, so no tests or research can be made.

If the ClientTarget attribute is not set, the HttpBrowserCapabilities object associated with the Page. Request attribute will reflect the functions of the client browser. If this attribute is set, browser detection is disabled on the client, and the page uses the browser function associated with the provided value (alias.

The root configuration file (Web. config) in the Web server computer defines four default aliases, which can be abbreviated as common user proxy strings:

• UplevelTo specify the browser function equivalent to Internet Explorer 6.0.
• Downlevel, Which is equivalent to the browser function of an older browser that does not support client scripts. You can use this alias to confirm how the webpage works in a browser with client scripts disabled.

You can use this attribute to set the alias string programmatically or useClientTargetFeature sets this alias in declarative form.

In the application-level Web. config fileClientTargetYou can define other aliases.

From

Although it cannot be verified, according to personal speculation, clientTarget obtains the browser alias Based on the User-Agent matching (which should not contain regular matches), so as to determine the browser type immediately, after obtaining the Browser alias, you can use the Browser alias to obtain the Browser function definition without matching browserCaps or Browser. ASP. net mvc may not include the use of clientTarget, but is only used in WebForm.

The ClientTarget of the Page class in WebForm is defined as follows:

Here, _ request is a sealed HttpRequest field. HttpRequest has no inheritance relationship with HttpRequestBase. The ClientTarget definition of HttpRequest is as follows:

After _ clientTarget is set, browsercaps is set to null, which corresponds to "if this attribute is set, client browser detection is disabled, the page will use the Browser function associated with the provided value (alias) ", but even if broswercaps is left blank, it will be assigned a value through Factory when obtaining the Browser attribute, the value is not another HttpBrowserCapabilities.

The test was conducted through reflection.

Defined clientTarget and browsercap

<clientTarget><add alias="IE10" userAgent="Chrome/52.0.2743.116 Safari/537.36"/></clientTarget><browserCaps><use var="HTTP_USER_AGENT"/><filter><case match="Chrome/52.0.2743.116 Safari/537.36">cookies=falsehopegi=mr.hopegi</case></filter></browserCaps>

 

HttpRequest request = System.Web.HttpContext.Current.Request;PropertyInfo propInfo = request.GetType().GetProperty("ClientTarget", BindingFlags.NonPublic | BindingFlags.Instance);propInfo.SetValue(request, "IE10", null);FieldInfo browserField=request.GetType().GetField("_browsercaps", BindingFlags.NonPublic | BindingFlags.Instance);object bVal = browserField.GetValue(request);

 

 

Note that System. Web. HttpContex is used here, but it is not the HttpContext attribute in MVC. It seems that Microsoft is somewhat frustrated with HttpContextBase and HttpContext.

Chorme before no value is set

After the value is set, the _ browser attribute is left empty.

In this case, the Browser attribute is obtained again and the result is no longer Chorme. Failed: the Browser type can only be set to Unknown, but other Browser types cannot be obtained.