Reputation: 341
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:
Add the following method (yes it's empty):
protected void Session_Start() { }
Set a breakpoint in the method
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?
I decided to use Fiddler to inspect the HTTP traffic during my debug session. It seems that:
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.
Upvotes: 5
Views: 10808
Reputation: 496
This happened to me when I had some <img>
in my pages with a wrong "src" attribute. Putting a valid path in "src" solved my problem.
Upvotes: 0
Reputation: 61459
Reason you are getting Session_Start
firing each time is because you have <httpCookies requireSSL="true" />
in <system.web>
in your Web.Config
remove this and you are good to go.
Upvotes: 1
Reputation: 61
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...
Upvotes: 6
Reputation: 22810
I can't reproduce this problem. I've tested on ASP.NET MVC 3/Tool Update, Win08/R2/SP1 and Win7/SP1 using IIS 7.5, Cassini and IIS Express. I see the 404 favicon request in Fiddler, but the break point is not hit for favicon. I tested with IE9, the current FF and Chrome. Each time I hit the site with a new browser, Session_Start() is called and I see the new session ID. I work for Microsoft so I'd like to know how to reproduce this problem.
Upvotes: 0
Reputation: 341
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:
Again, both seem like hacks to me, as I think this is something controller factories should be capable of handling gracefully. IMHO
Upvotes: 2