views:

3507

answers:

4

I'm hoping someone can clarify this behavior for me, and explain how ASP.NET is deciding when to treat something like a new Session.

A) In Internet Explorer I load the ASP.NET site in question. It starts a new Session.
B) If I go to menu File - New Window... it stays within the same Session.
C) If I launch a new instance of Internet Explorer and load the same page it starts a new Session.

I'm confused by step C. I'm expecting it to be the same session based on my remote IP.
What is IIS / ASP.NET doing to decide that this is a new session? Is it looking at my remote port that the new instance of IE is using? When you kick up a new window with File - New it uses the same remote port as the parent.

A: 

I'd wonder if the new IE instance would have the same cookies that happen in case B, where while it is a new window it is using the same process. It is usually in the cookie or in the querystring that there is a value used to map sessions to various clients.

JB King
+3  A: 

By default, ASP.NET tracks sessions through cookies. A new IE instance does not have the session cookie, resulting in a new session. However, using File -> New Window from an existing IE window will create a new window with the same cookies as the "parent", allowing ASP.NET to use the existing session.

J c
I should also note that IIS and ASP.NET don't really have anything to do with the difference in behaviour you are noticing. Also, keep in mind that sessions do not rely on remote IP address, which is often the same for many users (ie. a proxy).
J c
Your exactly right about the remote IP... should have thought of that. Is session cookie (versus regular cookie) part of the HTML spec?
tyndall
I don't believe it's part of the spec, a session cookie isn't really any different than any other cookie except that's its value happens to hold a unique identifier that is also "known" to ASP.NET. This cookie is typically transmitted as an HTTP header according to the HTTP spec though.
J c
Note that when cookies are disabled, a session can still be maintained by using a GET/POST parameter to pass the session key around. The server embeds this as a hidden field in a form or alternatively as part of the URL, which causes the browser to include the key in the next request.
J c
If you want to see what is happening under the hood, check out ieHTTPHeaders which will install a "View->Explorer Bar->item" into IE that lets you watch the HTTP header traffic. For example, in scenario B you could see how the browser transmits the session cookie to the server right from the start.
J c
A: 

It would appear the session data is getting cached per process. A) and B) exist in the same process, whereas launching a new instance of IE will be creating a new process.

KiwiBastard
+10  A: 

Sessions in IIS/ASP.NET are based on cookies with a session scope, meaning that they get destroyed when the browser is closed, and apparently they are not shared within different processes of Internet Explorer.

When you open a new browser window with File > New Window the window will be handled by the same process as the first (i.e. the same iexplorer.exe). When you lauch IE from the start menu you get a new process, and you will now have two iexplorer.exe in the Task Manager. I think that it's only IE 7 that will spawn multiple processes.

As a side note, IE 8 will have have a single process per tab / window, like Google Chrome has. I don't know if these browsers share session cookies amongs the processes, but it's certainly something to keep in mind when testing using one of these browsers.

Jan Aagaard
IE6 did it too. Not sure about 5.
GalacticCowboy