Session State and the Integrated Pipeline in Sitecore

Currently (release 090120) Sitecore has a known issue when it comes to running in the new IIS7 Integrated Mode pipeline. The issue states: "The ASP.NET session state may be unavailable to web page’s code depending on the URL used to access a Web site’s homepage. This occurs with a short URL, such as http://mysite.com/, while longer URLs, such as http://mysite.com/default.aspx do not encounter the issue. "

It actually goes a bit further than that. I did some testing on a completely fresh 090120, Created "Test1" under "Home". And then "Test2" under "Test1". Like so.

• Sitecore
• Content
• Home
• Test1
• Test2

I set up my website to run 32 bit Integrated Pipeline, with a binding to host header "integrated".

I then added some test code to the Sample Layout.aspx, like so.

<% string lala; if ( HttpContext.Current.Session != null ) lala = "Session has value"; else lala = "Session is NULL"; Response.Write( lala ); %>

(Extremely bad coding practice however, don't do this in any real scenario :P Breaks preview and page editor and whatnot... was just to test)

Now, after navigating to the following URLs, I was getting these results.

http://integrated/ "Session is NULL"
http://integrated/default.aspx "Session has value"
http://integrated/test1 "Session is NULL"
http://integrated/test1.aspx "Session has value"

Ok so. A known issue and according to Sitecore Support, no immediate ETA for a fix. Why would you want this however? Well let's consider SEO. Often have I been met with the requirement that SEO friendly URLs are required. And for some reason, SEO specialists seem to think that http://integrated/products/classical-piano is a better URL than http://integrated/products/classical-piano.aspx. Whether they are right or not, I leave with someone who knows more about these things than I do. Bottom line is, I needed these types of URLs for a client of mine. And I was curious :P

According to Microsoft, the list of Breaking Changes for Integrated Pipeline isn't all that long, and none of those stood out to me as something that should be affecting Sitecore. After much digging around, searching the web and reading lots and lots of articles about this new Integrated Pipeline - many of which was full of praise but none really helping me in any way - I finally came across something from someone who knew "what's what". ASP.NET Session State for Native HTTP Requests in IIS 7.0 Upon reading, I felt 99% sure this was the fix I was looking for. A bit of coding, and a bit of optimisation (read through the comments) and I was ready to give it a shot. And it worked :-) A bit of coding (or rather, code pasting), a compile, a simple web.config change and voila. Now all of the above URLs seem perfectly happy to give me the Session State I've come to rely on. If you can't be bothered to set up a project for this yourself, I'm attaching the project and the DLL. Just plop the DLL into your /bin folder and add the following to your web.config at the end of the system.webserver/modules node.

<add name="CorePointIntegratedSessionFix" type="CorePoint.IntegratedSessionFix.Module, CorePoint.IntegratedSessionFix" remove name="Session" add name="Session" type="System.Web.SessionState.SessionStateModule" preCondition="" /> (excuse the markup, I am REALLY not happy with my blog texteditor.. but that's a story for another day) And the project file here: CorePoint.IntegratedSessionFix.rar Enjoy :-)

Caveat: Be aware however, I don't have the resources to execute a complete regression test of this fix. It seems fine, but there could be repercussions that I am not seeing at this stage. I have an open support ticket with Sitecore Support on this issue; and I will post these findings there for their review. Will update if needed.

Update 23-February-2009 While eating my own dogfood on this fix, I was experiencing some fairly odd behaviour when using the Sitecore Content Editor. It would pause ever so often for a few seconds, and sometimes operations would get aborted and throw up a dialog box like "Session Terminated Unexpectedly". Quite naturally I was worried this had to do with this fix. Turns out, it hasn't. It IS related to the integrated pipeline however - I had overlooked another issue from the Known Issues List which states: A known issue in Microsoft IIS may cause Sitecore to restart during index rebuilding or package installation when Sitecore indexes are stored below the Sitecore web site root folder.Moving the Sitecore indexes outside website root will resolve the issue.To configure this, add the following to the "settings" section of web.config file: setting name="IndexFolder" value="C:\test\indexes" Note: You must ensure that the application pool identity has full control over the chosen index folder. For more information about appropriate folder permissions, please refer to the Sitecore CMS 6 Installation Guide. So if you do run integrated, don't get caught by this one. Like I just did :-)

Update: 6-March-2009 This has now passed Sitecore QA and is an official workaround according to SDN.