It is widely known that cookies are not welcomed on some user’s machines. A cookie is a small file of text (whose maximum size usually ranges from 4 to 8 KB) that web applications can create on the user’s machine. Once installed, cookies are then moved back and forth with each request for a certain domain. Cookies are also the default method for persistently storing a session ID. When a user starts a session, the infrastructure of the web application generates a new session ID and assigns it to the request. This ID—a 15-byte long sequence of URL-compliant characters—is placed in a cookie with a particular name, attached to the output response, and sent to the client. Next time, that cookie will automatically be appended to the request and retrieved on the server by the same infrastructure that created it. When this happens, the ASP.NET infrastructure has recognized successfully the (possibly anonymous) user making the request. The session ID is used as a selector into the session state storage system and the session state can finally be retrieved and bound to the page.
The browser plays a fundamental role in this machinery. What if cookies are disabled in the browser’s configuration? Nicely enough, ASP.NET introduces cookieless sessions. In a cookieless session, the session ID is maintained on the server to the extent that it is possible. Enabling a cookieless session is a matter of tweaking the application’s web.config file. For architectural reasons, the session mode can’t be changed on the fly. No matter how the retrieval of the session ID is implemented, your way of programming against the session state is unchanged. Let’s see the tricks that make cookieless session ID management happen.
In ASP.NET 1.1, the session state management is governed by an HTTP module that captures the AcquireRequestState and ReleaseRequestState application’s events. When the state is attached to the HTTP context of the request, the module reads about the cookie support in the session state from the web.config file. If the cookieless attribute of the <sessionState> section is set to True, the module attempts to get a session ID from the URL of the request. A “normal” request doesn’t contain any session ID in the URL, so the module generates a new session ID and starts a new session. The newly generated session ID is inserted in the URL just before the page name, as follows:
http://www.contoso.com/pages/(session ID)/default.aspx
Next, the module redirects the browser to the above URL using the HTTP 302 command. Another component plays a key role in the implementation of cookieless sessions—aspnet_filter.dll. This system component is another module in charge for checking the URL format whenever a new ASP.NET request comes in. If the URL being processed has the above format—that is, contains a bracketed session ID before the page name—it extracts the session ID and rewrites the URL so that it now points to a real, existing resource. The session ID is copied into a well-known request header (the name is hardcoded to AspNetFilterId), retrieved by the session module, and used as the session ID for the request.
This mechanism works great for requests that contain relative URLs and all postbacks. Whenever a request is made for an absolute URL, a new session is started. To work around it, you can use the ApplyAppPathModifier method on the HttpResponse object to munge the real URL you want to reach and have it added the ID of the current session.
Dino Esposito is Wintellect's ADO.NET and XML expert, and a trainer and consultant
based in Rome, Italy. Dino is a contributing editor to Windows Developer
Network and MSDN Magazine, and the author of several books for Microsoft
Press including Building Web Solutions with ASP.NET and ADO.NET
and Applied XML Programming for .NET. Contact Dino at [email protected].
