Is it possible to disable the browserCaps functionality in ASP.NET?

Question

Is it possible to disable the browserCaps functionality in ASP.NET?

I wish my site to be served reliably and exactly as I have it defined to all browsers regardless of their capabilities.

If their browser can't support the site, that's their problem. My site should not be some how attempting to degrade itself to accommodate the defunct client.

This is very frustrating when it seems to have the bad luck of spiders I guess crawling the site, getting the lesser version of the site causing output caching to serve the stripped file.

Henpeck

@Svend were you also aware that changing the user agent can alter the output in bundling/minification? Covered in this SO post and a little more in depth in this blog post. – Birecree

@Birecree No, but I'm not surprised. I've previously wrangled with phantomjs and this "feature". The current incarnation I'm looking at is HTML text encoding, we're seeing 'ø' being rendered as either ø in Chrome or ø in IE, the funny thing is that when we run the website locally the rendering is reversed (IE gets the two entities, while Chrome gets the one). – Vulgate

@Birecree Using the browsercap file to toggle functionality is probably the most hideous thing I've seen in web technologies in the last 10 minutes. – Vulgate

Answer 1

You can put ClientTarget="uplevel" in the page directive or in the Page.Init

<%@ Page ClientTarget="uplevel" ...... %>

or

Protected Sub Page_Init(ByVal sender As Object, ByVal e As System.EventArgs) _
        Handles Me.Init
    Page.ClientTarget = "uplevel"
End Sub

Another option is to add a .browser file to your site, in the folder App_Browsers (a default Asp.NET folder). It should target all browser with a regex expression and somehow disable the normal browser detection by adding capabilities. I'm only using this to render the Menu control the right way in Safari but I don't exactly know how to do this for all output at once.

Dennard

Answer 2

An insane workaround I'm currently trying out is to inject our own HttpCapabilitiesDefaultProvider which returns a static HttpBrowserCapabilities. The trick then is to always return the same capabilities object, so by calling base.GetBrowserCapabilities while using IE9, we've used Newtonsoft to create a serialization, and by saving this string in the source, we can build an IE9 like capabilities object regardless of what browser initiated the request.

public class CustomerHttpCapabilitiesProvider : HttpCapabilitiesDefaultProvider
{
    private const string m_IE9Definition = "{\r\n  \"$type\": \"System.Web.Mobile.MobileCapabilities, System.Web.Mobile\",\r\n  \"UseOptimizedCacheKey\":..... ";
    private readonly static Lazy<MobileCapabilities> m_Capabilities = new Lazy<MobileCapabilities>(() => JsonConvert.DeserializeObject<MobileCapabilities>(m_IE9Definition), true);

    public override HttpBrowserCapabilities GetBrowserCapabilities(HttpRequest request)
    {
        return m_Capabilities.Value;
    }
}

and then assigning the provider in Application_Start:

HttpCapabilitiesBase.BrowserCapabilitiesProvider = new CustomerHttpCapabilitiesProvider();

This hasn't really been tested however, unsure of what exactly is the impact of this change.

Vulgate

Doesn't sound insane to me that sounds like the closest to disabling it as possible. – Henpeck