Yes, there is a cookie.  Isn't that the normal mode of operation?

I think the question is why isn't your system using cookies?  Are your browsers working in super private (porn) mode?  Do you have a cookie blocker active?

We'll get to the bottom of this one way or another...

No, I don't have a cookie blocker, and in fact sessions work fine from my app.  As you can see from the HTTP request/response, the Set-Cookie header isn't present in the response, in spite of the fact that I have sessions enabled.

If the cookie is present, then the behavior you're seeing is expected: you will see the same session ID for each request from the same user.  That's because the session ID is stored in the cookie.

The point I was trying to make is that the session cookie itself won't be set until you store something in the Session dictionary.  If you just enable sessions for your site, but never use the Session object, then the session ID cookie will never be set.  In that case, the session ID will be different for each request.

So, the fact that you're seeing the same session ID means you have a cookie set.  Check.  The fact that you have a cookie set means that some recent previous page from the same site set a value in the Session dictionary, which is what caused the cookie to be set....

To see it yourself: either close your browser to delete the cookie, or use Firefox or Chrome to delete it by hand.  Assuming a vanilla site with no custom HttpModules, access a page that just displays the session ID -- it will be different every time.  If you look at the HTTP headers, you'll see that the session cookie isn't set.

I used the Internet Explorer Toolbar to clear both session and all domain cookies.

As expected, the SessionID changed.

However subsequent refreshes and postbacks continued to use the new SessionID that is constant.

Nothing is being stored in the Session dictionary.

RickNZ:

The point I was trying to make is that the session cookie itself won't be set until you store something in the Session dictionary.

I don't believe that.

From this link:  http://msdn.microsoft.com/en-us/library/ms178194.aspx

Cookies and Session State

There is nothing mentioned that an object has to be placed in the dictionary.

It sounds like you have session state turned off on your site:

http://msdn.microsoft.com/en-us/library/ms178581.aspx

You can disable session state for an application by setting the session-state mode to Off. If you want to disable session state for only a particular page of an application, you can set the EnableSessionState value in the @ Page directive to false.

Rick,

I have spent couple of hours playing with the session to see what the confusion is about... Here is what I found.  Please feel free to correct me if you found something wrong

RickNZ:

1. An explicit call by the server to Session.Abandon(). That will delete the session cookie and call Session_End().

Session cookie is not really removed from the browser. Session is simply ended at the server and Session_End is called and the Session ID may be reused for the subsquent request from the same browser instance.. Here is a microsoft KB article regarding this

http://support.microsoft.com/kb/899918

RickNZ:

2. No action by the server; the session just ages past its intended life time.  Session_End() won't be called in that case. 

Session_End is called at every instance in the "InProc" mode. You might see weird behavior when you are debugging in the VS.NET, but in normal execution Session_End is called everytime session ends, either its by calling Session.Abandon or automatic session time out

I used the following code to check this behavior

 void Session_Start(object sender, EventArgs e) 
    {
        StreamWriter SW;
        SW = File.AppendText(@"D:\test.txt");
          SW.WriteLine("Session ID: " + Session.SessionID);
        SW.WriteLine("Session Started at: " + DateTime.Now.ToString());
        SW.Write("\n");
        SW.Close();

    }

    void Session_End(object sender, EventArgs e) 
    {
        StreamWriter SW;
        SW = File.AppendText(@"D:\test.txt");
         SW.WriteLine("Session ID: " + Session.SessionID);
        SW.WriteLine("Session Expired at: " + DateTime.Now.ToString());
        SW.Write("\n");
        SW.Close();
    }

RickNZ:

Until you store something into the Session dictionary for a given user, the session HttpModule will not set a session cookie.  Until the session cookie is set, the session HttpModule will create a new session for each request; that includes a new session ID.

This is true, unless you have a handler defined in the Global.asax page for Session_Start or Session_End. If these handlers are not defined a new Session ID is generated for every request, when there is nothing stored in the Session bag

I do not have a proper reasoning why this behavior. Please explain if you find anything

Kumar Reddi:

This is true, unless you have a handler defined in the Global.asax page for Session_Start or Session_End. If these handlers are not defined a new Session ID is generated for every request, when there is nothing stored in the Session bag

Kumar,

That is VERY helpful.  I had session handlers in Global.asax.  When I removed them, I got a new sessionID with every page request.

Kumar Reddi:

I do not have a proper reasoning why this behavior.

Nor do I understand why they would do this.  Maybe it's some perveted attempt at optimization.  However generating a new SessionID with every page request must entail a bit of overhead.

Thank you Kumar.

Kumar, I agree -- good detective work; thanks for helping us figure out the session ID behavior.  Definitely an odd case that I haven't seen before.

The reason the runtimes generate a new session ID for each request by default is that sending the session ID cookie to the client, and then having the client send it back to the server for every subsequent request involves some overhead -- if the cookie isn't there, then the overhead can be avoided.  And you (normally) don't need the cookie unless/until you store something in the Session dictionary.

BTW, if you try to access the Session object or the Session ID with sessions disabled, the runtime will throw an Exception, so my previous example wouldn't work unless sessions were enabled.

Also, as a general rule of thumb, I strongly discourage InProc or State Server as a session store -- lots and lots of corner cases; headaches are a near guarantee at some stage.

No Problem guys. Its surprising to see that there is so much undocumented and weird stuff about session state even after these many years since asp.net came out

Kumar Reddi:

Session cookie is not really removed from the browser. Session is simply ended at the server and Session_End is called and the Session ID may be reused for the subsquent request from the same browser instance.. Here is a microsoft KB article regarding this

http://support.microsoft.com/kb/899918

Yes, That's true. It was reported several times in these forums. Example..http://forums.asp.net/p/1446995/3482221.aspx

Kumar Reddi:

This is true, unless you have a handler defined in the Global.asax page for Session_Start or Session_End. If these handlers are not defined a new Session ID is generated for every request, when there is nothing stored in the Session bag

Hum...I didn't know this. Thanks for posting!!