Introducing Browsers Providers in ASP.NET 4

Posted by Matthew Osborn on March 11, 2010

In ASP.NET there is a concept of Browser Capabilities, they define what the device that issued the request to the site is capable of doing. For instance things like “Supports JavaScript” and “Supports Frames”, they also provide other meta information about the device such as the Name and version number. I’ll be the first to say that most of the values that are in there are no longer really useful. For example that is a property called “Is AOL”, yes I’m not kidding but at some point in time you wanted to know these things. I’m not going to spend any more time talking about what Browser Capabilities But if you don’t know you might consider watching this before continuing. Also, you might want to check out the Mobile Device Browser File on codeplex.

Okay so what is the big deal with the Browser Providers? In previous versions you had two options if you wanted to modify or extend how ASP.NET determined the devices capabilities. The first is to modify the Machine level browser file in the framework directory. The second is to add a .browser file to the App_Browsers folder in the website, which gave you website level control. If you look at the File Scheme for the .browser files you will quickly see how this could be a problem if you wanted to do any dynamicish stuff because it was just a flat file.

Okay so now you understand the problem you can understand how Browser Providers fix the problem. They are a special type that is registered in application wide that has methods that are executed on each request and allow you to add, remove, or modify capabilities in the browser capabilities collection. The easiest way to do this is to inherit from our default provider and override the methods.

  1. public class CustomProvider: HttpCapabilitiesDefaultProvider
  2. {
  3.     public override HttpBrowserCapabilities GetBrowserCapabilities(HttpRequest request)
  4.     {
  5.         HttpBrowserCapabilities caps = base.GetBrowserCapabilities(request);
  6.         caps.Capabilities["Used www"] = request.RawUrl.Contains("www.");
  7.         return caps;
  8.     }
  9. }

In this example I am just looking at the url that was used to make the request and seeing if the device/user put “www.” in front of the request. Not really useful but it is a demo. Also, remember that this is executed for each request so the code that goes in here should be Very speedy. You do not want to hold up the request while the provider goes and talked to a database. Now that you have your provider you need to register it with the application. You can do this is the browserCaps in the web.config or you can register in the Global.asax, like so.

  1. void Application_Start(object sender, EventArgs e)
  2. {
  3.     HttpCapabilitiesBase.BrowserCapabilitiesProvider = new CustomProvider();
  4. }

Now your provider will run on each request, it’s pretty simple I know. The main thing to remember is that because it run on each request it should be lightweight code that executes and honestly this should be one of those time where creating a browser provider is the last resort, in my opinion at least.