Session_Start firing multiple times on default ASP.NET MVC3 project

Question

I think I may have found a problem with ASP.NET MVC and it's event pipeline. In particular, I am finding that Session_Start is being called multiple times, each containing a new SessionID.

Here's the step-by-step process:

1. Open VS2010
2. File | New Project
3. ASP.NET MVC 3 Web Application, accept default name, click OK
4. Select Internet Application (although I don't think it matters really), click OK
5. When finished creating, edit the Global.asax.cs file

6. Add the following method (yes it's empty):

   protected void Session_Start() { }

7. Set a breakpoint in the method

8. Debug
9. Notice that the breakpoint is caught twice before displaying the page. If you watch "Session.SessionID" when the breakpoints are caught, you will see that the session id is new each time.
10. Once you get to the home page, click on the "Home" or "About" tab link.
11. Session_Start will be fired again, this time with a new SessionID.
12. Continue execution, and any subsequent actions will no longer fire Session_Start.

I tried the same thing on a standard ASP.NET Web Application (not MVC), and Session_Start only fired once.

I'm pretty sure I'm not doing something wrong here, as I am using the default project templates, and the only code that is being modified is the Global.asax.cs file, to add the Session_Start method.

I am using IIS Express, but I've repeated the above steps using the "Cassini" web server (Visual Studio Development Server), with the same result.

Any advice?

UPDATE

I decided to use Fiddler to inspect the HTTP traffic during my debug session. It seems that:

1. The first Session_Start is fired when I am requesting the "/" URL. This seems reasonable. The SessionID generated at that time is then written in the response to the browser. Again, seems reasonable.
2. Fiddler then shows requests/responses for the *.js and *.css files. All successes. None of those fire off Session_Start. Good so far.
3. Then Fiddler shows that a request has been made for "/favicon.ico". At this time, Session_Start fires, and generates a new SessionID... I continue.
4. On Fiddler, it shows that the "/favicon.ico" file was not found (404). The webpage is displayed. I click on the "Home" link.
5. The URL "/" is requested and response is OK in Fiddler. But then, another "/favicon.ico" file is requested, and again Session_Start fires with a new SessionID... I continue.
6. All subsequent requests have responses, and the browser stops asking for "/favicon.ico".

I made note of each of the three SessionID's generated, and it seems the one that the browser holds on to is the first one. So when we get to step 6 above, and everything seems to work, it's actually using the very first SessionID that was generated.

So... I decided to host a "favicon.ico" file. I placed the ico file in the root of the project, and started my debug session again. This time, Session_Start only fires once. "/favicon.ico" was served successfully (200).

So... I guess it is working the way it should in a sense... But why do calls to "/favicon.ico" fire off the Session_Start event???? Shouldn't I have the choice to NOT host a favicon?

ASIDE: I tried all the above in an ASP.NET (not mvc) project, and it did not have the same problem, even though there was no favicon.ico file hosted by a default "ASP.NET Web Application" project.

Answer 1

I kinda had this problem for a while, and finally I realised that it was because there was some http/https shenanigans going on... looks like it destroys and recreates your session if you flip the ssl around like that and you have

<sessionState mode="InProc" sqlCommandTimeout="3600" timeout="120" cookieless="false" />
<httpCookies httpOnlyCookies="true" requireSSL="true" />

Possibly a trap for new players or people who are really tired and not paying attention! :) Just FYI in case this helps anyone...

Answer 2

I think I've come to a point where I have a couple of solutions (albeit both seem 'hacky' to me), so I think I'll accept these and move on.

Got a comment from @Tz_ above that mentioned I should ignore the route for the favicon file. That's essentially what I'll be doing. (kudos @Tz_!)

Came across the following post, (among others). It describes a problem that when the browser requests a "/favicon.ico" file from an ASP.NET MVC site, the MVC stack is mistakingly trying to look for and instantiate a controller. I'm wasn't sure if that was true or not for my situation, but the answer suggested adding the following route entry:

routes.IgnoreRoute("favicon.ico");

I gave it a shot (added the above), and that fixed it!

So, I still don't know why "/favicon.ico" request has a mistaken identity in MVC, but I know how to fix it in my situation. Either:

• Host a favicon,
• or add an ignore route entry.

Again, both seem like hacks to me, as I think this is something controller factories should be capable of handling gracefully. IMHO