Tracking Session State

Because Web-based applications rely on HTTP to connect browsers to servers and HTML to represent the state of the application, ASP.NET is essentially a disconnected architecture. When an application needs to use session state, the runtime needs a way of tracking the origin of the requests it receives so that it may associate data with a particular client. ASP.NET 2.0 offers three options for tracking the Session ID, via cookies, the URL, or client profiles.

Tracking Session State with Cookies

This is the default option for an ASP.NET Web site. In this scenario, ASP.NET generates a hard-to-guess identifier and uses it to store a new Session object. You can see the session identifier come through the cookie collection if you have tracing turned on.


Tracking Session State with the URL

The other main option is to track session state by embedding the session ID as part of the request string. This is useful if you think your clients will turn off cookies (thereby disabling cookie-based session state tracking).


Using AutoDetect

By selecting AutoDetect, the ASP.NET runtime will determine if the client browser has cookies turned on. If cookies are turned on, then the session identifier is passed around as a cookie. If not, the session identifier will be stored in the URL.

Applying Device Profiles

The UseDeviceProfile option tells ASP.NET to determine if the browser supports cookies based on the SupportsRedirectWithCookie property of the HttpBrowserCapabilities object set up for the request. Requests that flip this bit to true cause session identifier values to be passed as cookies. Requests that flip this bit to false cause session identifiers to be passed in the URL.

Session State Timeouts

The timeout configuration setting manages the lifetime of the session. The lifetime of the session is the length of time in minutes a session may remain idle before ASP.NET abandons it and makes the session ID invalid. The maximum value is 525,601 minutes (one year), and the default is 20.