Developing Web Applications

ASP Sessions Are Cookie-Based

ASP uses HTTP cookies to identify user sessions with unique session keys. Once an ASP session begins, ASP responds to a user’s request with a Set-Cookie HTTP header. From that point on, each browser request is identified by the session ID cookie.

Web Clusters and ASP Session State
ASP session information is stored in memory on the Web server, which creates a challenge for sites using ASP in a Web cluster environment. Web clusters balance the load of user requests among a number of Web servers. In order to use ASP Session management, the same Web server must handle all requests from a user for the life of the session, a prerequisite that most load-balancing schemes cannot guarantee.

Several options are available if you want to use ASP in a Web cluster:

Write your own session management logic to replace that provided by ASP. Keep your session state in a centralized place, such as a database.

Use a third-party solution. For example, Cisco Systems’ LocalDirector hardware load balancer can ensure that the same client gets the same server for multiple connections.

Load balance new requests but, once a session begins, make sure that all subsequent requests return to the same server during the life of the session. This technique is called ASP session-aware load balancing.

ASP Session-Aware Load Balancing

In this scenario, all new requests continue to use the existing load-balancing mechanisms, such as round-robin Domain Name System (DNS), for distributing requests to a site’s published URL. Then, during the Session_OnStart event, the script in an ASP page uses the Response object to redirect the browser to the application’s start page by using the local computer’s own Internet Protocol (IP) address or unique name, as follows:

Response.Redirect("http://w10.microsoft.com/Webapp/firstpage.asp")

Finally, to ensure the browser will confine its requests to the same Web farm server, all application links must be relative URLs. Relative URLs only specify path information relative to the current location, for example:

<A HREF="MyAsp.Asp">...</A>

<FORM METHOD=POST ACTION="./SubDir/FormAction.asp">...</FORM>

When one of these links is selected, the browser will construct the full URL path using the current address (specified in the redirect) and the relative URL, thus enabling it to locate the computer hosting the user session.

This technique may not be appropriate for all Web applications. Also, if users save URLs on their browsers using favorites or bookmarks, they will return to a specific computer, which can defeat the purpose of proper load balancing.

Here’s an example of an ASP session ID cookie:

Set-Cookie: ASPSESSIONIDGGGGGJZB=EFENHLNDIIEHJGJOAGICNPEK; path=/

This is different from earlier versions of ASP, which would set the cookie path to that of the ASP application’s virtual directory. In IIS 5.0, only one cookie is sufficient for all applications on the server. Once the cookie is received, every browser request includes the same HTTP cookie header:

Cookie: ASPSESSIONIDGGGGGJZB=EFENHLNDIIEHJGJOAGICNPEK

ASP uses this value to retrieve the correct Session object for the client connection. All requests to the application directory include the session ID cookie, even those for static HTML content in subdirectories of the ASP application. In this example, the cookie does not specify an expiration time, so it is only valid as long as there is an open client session. The cookie expires when the user closes the browser.

Note If a user chooses not to accept the ASP cookie (or if the browser fails to return it in subsequent requests), the application will not be able to map the browser request to an existing Session object and will create a new one.

It is possible for several browser instances to share the same cookie (which means that more than one browser window can be accessing different sections of your application at the same time), but make modifications to the same Session object. This is especially bad for applications that make heavy use of session state, and is another reason to use session state only when necessary.

ASP session IDs are mapped to the in-memory Session object on the server. This works well when only one server is managing the user session. When using ASP in a Web cluster, however, more than one server may be handling the user’s request. For more information about how to manage session IDs in a Web cluster, see the sidebar, Web Clusters and ASP Session State.