ASP.NET & IIS7 : URL Routing + IHTTPHandler + Session State?

URL Routing is one of the newest addition Microsoft has added to ASP.NET. There’s quite a lot of information on the web that talks and explains it. Today though, I found a problem with it that I’ve been trying to figure out, but so far I only came up with a solution that doesn’t make any sense.

Let’s first talk about URL Routing & IIS7. To start a URL Route, we must first fill a RouteTable with Routes so that the URLRoutingModule can later use it. In my case, I usually do this in the Application_Start of the global.asax file. In the ASP.NET pipeline, a bit later, the URLRoutingModule is then called between the application.PostResolveRequestCache and the application.PostMapRequestHandler events. The URLRoutingModule then takes the routing table defined earlier in the Application_Start and searches to see if a route is found. If a route is found, the module then takes the IHTTPHandler associated with that route and add’s it to the MapRequestHandler. Later on in the pipeline, the Managed IHTTPHandler should fire when an event is called for them. You can find more information about the details here URL Routing, a good article written by Ruslan Yakushev with a good picture on this architecture (pipeline).

During this time, I was writing a JSON IHTTPHandler to send out information to the browser. As most of us knows, in order to use Session State with our IHTTPHandler (prefix = *.mini), we need to add either the IRequriesSessionState or IReadOnlySessionState marker interfaces to our handler class it. I then added the routes to my routing table. So I then tested it with Visual Studio’s 2008 debugger.

Results?

• localhost/site/junk.mini = Worked Perfectly as Expected!


• localhost/site/testroute = Worked Perfectly as Expected!

I felt really good about this so I then loaded up IIS7 and tried it there. Results?

• localhost/site/junk.mini = Worked Perfectly as Expected!


• localhost/site/testroute = SessionState Information Not Found???

So I did that and I got a error telling me that the Session doesn’t exist. After looking further, Odd, I say, because from the guide above, this handler should go through the System.Web.SessionState.SessionStateModule. Basically, what ends up happening next is searching the Internet until I found a partial solution. Loki in StackOverflow discovered that the AcquireRequestState wasn’t firing for some odd reason. The fix for this? Just re-add the System.Web.SessionState.SessionStateModule like this to the system.webServer section of your web.config:

<system.webServer>
<modules>
<remove name=”Session” />
<add name=”Session” type=”System.Web.SessionState.SessionStateModule” />
</modules>
</system.webServer>

I did the test again and it worked! So that fixed it, but why did it fix it? To find out that answer requires a little more digging. Since the .config files are inherited from the lower ones, there must be something that the lower ones are doing that the upper ones aren’t. A little searching and then you find Bilal Haidar’s blog on Session State and Native HTTP Requests in IIS7. This blog explains that the original SessionState is done via the applicationHost.config file. That session is defined as:

<add name=”Session” type=”System.Web.SessionState.SessionStateModule” preCondition=”managedHandler” />

So it added the preCondition=”managedHandler” so that the SessionStateModule would only work when it is a managed handler. Bilal then goes on talking about handling native events in managed mode. However, in my case, everything is managed. So what’s happening?

To test out this theory, I added the preCondition=”managedHandler” to my website’s web.config file, and guess what! Session State returned a null again!

So why in the world does this go through the URLRoutingModule get’s calculated and considered a “native” IHTTPHandler even though it is managed! I wish I knew why.

Update:
Part 2 Here