Sunday, February 13, 2005

HttpModules and Browser Capabilities

What do these have in common? Nothing, except that they both have to do with ASP.NET.

HttpModules

So I decide to implement my own HttpModule. I'm working on my Lexel Software website (it needs a bit at the moment) and decided to create my own stat tracker code. I've learned quite a bit through this experience. And since I'm not finished, I'm sure I'll learn more.

First, creating HttpModules in ASP.NET are simple. First, create a class that implements IHttpModule and add something to your web.config file. Voila! Done. This is a good way of firing off some code anytime a request is made.

Second, I wanted to have access to my SessionState data in my module. But, apparently, at that point you can't get to that data directly. So how do you solve that issue? As it turns out, it's not too hard.

You can have your module hook into ASP.NET request handling sequence at a number of points. Some of your options are to hook it up at BeginRequest, the Page Constructor, Page.Init, Page.Load, or EndRequest. But which one should you choose? I went with EndRequest. You see, the Init() method on the page has access to the HttpApplication.Context.Items collection. You can take any data that you want to have access to and put it into that collection. Then, on the EndRequest event handling method in your module, you can get the values out and deal with them accordingly. Cool.

Anyway, HttpModules are easy to build. So if you need per-request code run, it's a decent way of doing it. You can also have all your pages descend from a base page that all the others inherit from, and that works ok. But this way is pretty slick.

HttpBrowserCapabilities

An object of this class is associated with the HttpApplication as well, and by using it you do get access to some of the capabilities of the browser surfing your site. But it's not perfect, so I'm going to have to look outside of this a little.

Anyway, it is recognizing Firefox as Netscape. That's okay though, since not many people would be using Netscape today. Second, it doesn't tell you what version of the Clr that the user is running. This isn't surprising, of course. From their perspective, they probably don't care. But it would still be nice to know.

3 Comments:

At 8:41 AM, Anonymous Anonymous said...

You can parse the CLR version, for an IE user anyway, out of the UserAgent ServerVariable, if that'll help you at all.

 
At 8:51 AM, Blogger Eric Sowell said...

I should clarify. That info is available in the BrowserCapabilities object when an IE user is surfing. It's not available when a Firefox user is surfing. I should have made that more clear.

I wonder if the UserAgent var works as well with FF as it does with IE.

 
At 9:34 PM, Anonymous Anonymous said...

>I wonder if the UserAgent var works
>as well with FF as it does with IE.

I don't think so, unfortunantely. I just looked at mine (v1.0), and it's pretty bare bones. It *does* tell you that it's FireFox, as opposed to Netscape, but no dice on the CLR version. I suppose that makes sense, seeing as IE can actually host .Net applications, and Firefox obviously doesn't...Yet. at least.

 

Post a Comment

<< Home