views:

539

answers:

2

Does IIS create the session id when a request is received and where is that saved (client or server)?

How does server recognize that the request is coming from the same user/session?

+3  A: 

The answer to your first question is Yes -- if sessions are used, and Both.

A cookie is a short bit of text passed back and forth between client and server with every request/response.

IIS generates a session id, saves it, and any associated data, and passes the in a cookie to the client (browser).

When the client makes another request, it sends the cookie, containing the sessionID back to the server. The server can then look at the cookie and find the session (and the associated data) which is saved on the server.

chris
Is there a link somewhere on the web that can give me more information? I want to understand how cookie is transferred between the client and the server.
MOZILLA
Cookies are sent in the headers of the HTTP requests.http://en.wikipedia.org/wiki/HTTP_cookie
Kevin Tighe
+1  A: 

In ASP.net, there are multiple places for the session to be saved, but it's always within the server infrastructure.

The default is the memory of the IIS Process. This means: if you reset IIS (or the whole PC) or even just the application pool within IIS, all sessions are deleted, and the session data is lost forever. Also, if you have a LOT of sessions and store a lot of data in each session, the process will require a lot of memory, which can be a problem. This is called "In-Proc" Sessions.

The main alternative is a SQL Server Database. That way, sessions are kept even after a restart and it does not really matter how large each session is. The main downside is the added latency: Fetching data from a database is slower that the In-Proc solution of course.

There are also some other methods how to store sessions (including the option to write a completely new session provider), but the two common ones are "The Memory of the Server" and "A MS SQL Database".

Michael Stum