We're experiencing a problem where the session state isn't always initialized in our ASP.NET application when we're using out custom URL rewriting logic, IIS7, and integrated pipeline mode. Everything has been working fine for us in the past, but we'd like to switch from IIS6's ASP.NET wildcard mapping approach to the way MSFT recommends we handle our needs with IIS7 and integrated pipelining. I haven't seen any similar posts, so I figured I'd start a thread to see if anyone has any ideas on how to deal with this issue.

Here's what currently happens when a visitor comes to our production server (which is using the wildcard mapping method):

1. A visitor requests http://domain/account/12/13. The account/12/13 directory doesn't exist and is just a pretty URL.
2. One of our modules, IncomingLinkParser, implements an HttpApplication.BeginRequest event. Within that event, the URL is rewritten to look something like this: /default.aspx?value1=12&value2=13. We have no other HttpModules that perform any other URL rewrites or interfere in any other way.
3. That same module (IncomingLinkParser) implements an HttpApplication.PreRequestHandlerExecute event. Within that event, values are configured for the HttpContext.Current.Session collection.
4. The request is served and the visitor is happy.

However, here's what happens when we switch away from classic ASP.NET mode and into integrated pipeline mode:

1. A visitor requests http://domain/account/12/13. The account/12/13 directory doesn't exist and is just a pretty URL.
2. The IncomingLinkParser module, which is added under system.webServer/handlers/modules in web.config, implements the same BeginRequest and PreRequestHandlerExecute events. The IncomingLinkParser module has an empty preCondition attribute so that ALL requests are run through it (vs just managed requests or whatever).
3. The IncomingLinkParser's BeginRequest event rewrites the URL to look the same as in #2 above. It has an ASPX extension, so it should use the ASP.NET HttpHandler.
4. IncomingLinkParser's PreRequestHandlerExecute is hit. However, within this event, System.Web.HttpContext.Current.Session evaluates to null.
5. Since session values can't be set, an exception is thrown and the request fails.

In the example immediately above (where the exception is thrown), everything works if I instead issue one of the following requests:

1. http://domain/account/12/13/default.aspx
2. http://domain/account/12/13/fdashfjklhklasdjf.aspx (page doesn't exist)
3. http://domain/account/12/13/fdashfjklhklasdjf.asmx (page doesn't exist; notice this has an asmx extension)
4. http://domain/ (default.aspx exists in that directory, and the request to the application in BeginRequest comes in for default.aspx)

Notice that all of the requests that work in that example end in either .aspx or .asmx. I didn't try any other extensions that are handled by the ASP.NET handler by default, but I'm guessing others would work. My strong suspicion is IIS7 knew that it'd need to set up a session state as the request came in and so it did, but when the request was rewritten, it skipped setting up the session state but still used the ASP.NET handler. Anyway, in all of those examples, System.Web.HttpContext.Current.Session has been created by the time PreRequestHandlerExecute is fired, an so session values can be properly set and everything works great.

The only way I've been able to get around the issue is to add runAllManagedModulesForAllRequests="True" as an attribute to the system.webServer/modules element in web.config. In that case, session state is set up every time. However, I suspect performance wouldn't be as good in that case since EVERY module would then run all the time, which isn't what we want. IncomingLinkParser should "execute" every time since it can determine whether or not the request is for ASP.NET or if it can be handled by another HttpHandler (such as the static handler). The other custom HttpModule modules we have only need to run for managed requests for the most part, so there's no reason for them to run on every request.

I tried playing around with RemapHandler (http://msdn.microsoft.com/en-us/library/system.web.httpcontext.remaphandler.aspx) in ASP.NET SP1, but I can't find it at all in any of my assemblies nor could I find a single example of someone who had successfully used it. More on that in a follow-up post though.

Relevant config looks like this:

• IIS7 on Vista Business x64 machine (dev machine)
• ASP.NET 3.5 SP1 w/ Visual Studio 2008 SP1
• The web project is set to target ASP.NET 3.5
• 4 additional custom HttpModules are used under system.webServer/modules. Three have the preCondition="managedHandler" attribute set, and the other has preCondition="" set. None of the other modules interfere with session, URL writing, or anything remotely close to what's going on.

This seems like a bug to me, but perhaps I overlooked something. All that said, any ideas??

Hello,

I have the same problem and couldn't find similar threads so it's strange there are now two threads about this posted within two hours. My thread: http://forums.asp.net/t/1349901.aspx

I think your thread solved my problem though! I have had no problem with this before but I couldn't remember what I did differently but now I know. You need to set the runAllManagedModulesForAllRequests="True" attribute.

This is what I have been told, that you must set that attribute for extensionless url rewriting in IIS7... but I'm very interested in if it can be done in another way and I'll consider this a temporary solution and wait and see what comes out of this discussion for better performance.