Each active ASP.NET session is identified using a 120-bit string made only of URL-allowed characters. The session ID is generated using the Random Number Generator (RNG) cryptographic provider. The service provider returns a sequence of 15 randomly generated numbers (15 bytes x 8 bit = 120 bits). The array of random numbers is then mapped to valid URL characters and returned as a string.
The session ID string is communicated to the browser and then returned to the server application in one of two ways: by using cookies (as in classic ASP) or a modified URL. By default, the session-state module creates an HTTP cookie on the client, but a modified URL can be used—especially for cookieless browsers—with the session ID string embedded. Which approach is taken depends upon the configuration settings stored in the application's web.config file. To configure session settings, you use the <sessionState> section and the cookieless attribute.
<sessionState cookieless="true|false" />
By default, the cookieless attribute is false, meaning that cookies are used. A cookie is really nothing more than a text file placed on the client's hard disk by a Web page. In ASP.NET, a cookie is represented by an instance of the HttpCookie class. Typically, a cookie has a name, a collection of values, and an expiration time. When the cookieless attribute setting is false, the session-state module actually creates a cookie named ASP.NET_SessionId and stores the session ID in it. The cookie is created as the following pseudocode shows:
HttpCookie sessionCookie;
sessionCookie = new HttpCookie("ASP.NET_SessionId", sessionID);
sessionCookie.Path = "/";
A session cookie is given a very short expiration term and is renewed at the end of each successful request. The cookie's Expires property indicates the time of day on the client at which the cookie expires. If not explicitly set, as is the case with session cookies, the Expires property defaults to DateTime.MinValue—that is, the smallest possible unit of time allowed in the .NET Framework.
To disable session cookies, you set the cookieless attribute to true in the configuration file, as shown here:
<configuration>
<system.web>
<sessionState cookieless="true" />
</system.web>
</configuration>
At this point, suppose that you request a page at the following URL:
http://www.contoso.com/sample.aspx
What is really displayed in the browser's address bar is slightly different and now includes the session ID, as shown here:
http://www.contoso.com/(5ylg0455mrvws1uz5mmaau45)/sample.aspx
When instantiated, the session-state HTTP module checks the value of the cookieless attribute. If true, the request is redirected (HTTP 302) to a modified virtual URL that includes the session ID just before the page name. When processed again, the request embeds the session ID. If the request starts a new session, the HTTP module generates a new session ID and then redirects the request. If the request is a postback, the session ID is already there because postbacks use relative URLs.
The drawback of using cookieless sessions is that the session state is lost if an absolute URL is invoked. When cookies are used, you can clear the address bar, go to another application, and then return to the previous one and retrieve the same session values. If you do this when session cookies are disabled, the session data is lost. For example, the following code breaks the session:
<a runat="server" href="/code/page.aspx">Click</a>
If you need to use absolute URLs, resort to a little trick and manually add the session ID to the URL. You use the ApplyAppPathModifier method on the HttpResponse class.
<a runat="server"
href=<% =Response.ApplyAppPathModifier("/code/page.aspx")%> >Click</a>
The ApplyAppPathModifier method takes a string representing a URL and returns an absolute URL, which embeds session information. For example, this trick is especially useful in situations in which you need to redirect from a HTTP page to an HTTPS page.
