,

Introduction

Session Management is fundamental to any web application. In the article we shall try to understand what goes on beneath the hood of HTTP headers for session management.

Session management in ASP.NET can be done in two ways:

Using Cookies

Encoding of URLs with Session ID

Let’s try to understand both these methods by analyzing the HTTP headers sent between the browser and Server.

Cookie-based Session Handling

To enable cookie-based session handling, make sure that web.config file of the web-application contains the following entry:

<sessionState mode="InProc" cookieless="false" timeout="20" />

Let’s say the browser makes a request to a server. This is the first request from the browser to the server. For e.g. for a request: http://localhost/WebApplication1/WebForm1.aspx the HTTP request header sent by the browser would be as shown below:

Let’s try to understand this header information. The first line shows the type of HTTP request (GET/POST/HEAD) etc, followed by the URL of the resource. The second line declares the MIME type which the browser is capable of handling. The third and fourth lines show the default language and encoding. The fifth line contains information about the browser. This information may be used by the server to identify the browser from where the request is coming. The sixth line contains the address of the server to which the request is made. The seventh line indicates that the browser would keep the connection alive for future requests. The response send back by the server would consist of a HTTP response header and response body. The response header would look something like this:

Let’s try to understand the line of our interest. The first line indicates the HTTP Status code returned by the Server. “200” Status code indicates that the request was successfully executed. The sixth line shows the cookie that’s send by the Server. This cookie contains the Session ID that is a unique ID generated by the server. The Set-Cookie header instructs the browser to store the cookie in its cache. Now for all further requests this cookie is send back to the server by the browser. For e.g. if the browser clicks on a button of the first page to make a request to WebForm2.aspx, the request header sent would be:

As we can see, the next request the browser makes, it passes the session ID as a cookie back to the Server. The server extracts this session ID from the cookie and maps it to the Session object on the Server side. Thus the session ID is passed to and fro in every request and response. This enables the Server to track a user on the Server side.

Cookie-less Session Handling

For cookie-less Session handling we need to set the ‘cookieless’ attribute to ‘true’ in web.config.

<sessionState mode="InProc" cookieless="true" timeout="20" />

Now let’s make a request, for e.g. http://localhost/WebApplication1/WebForm1.aspx and have a look at the request header. Note: Open a new instance of the web browser, so that the old session ID is used. The request header is as shown below. (Similar to earlier request header in cookie-based session handling)

The first response send by the server contains the HTTP status code: 302 This status code instructs the browser to redirect the request to a new URL specified by the Location attribute in the response header. So the browser makes a second request with the new URL. The Request header it sends would be as shown below:

It’s important to note that in the above response header, the Server has not passed any Session ID cookie to the browser. Now the big question is what happens for future requests. Suppose we have a relative URL in the first page pointing to a second page as shown below:

Now when ‘Webform2.aspx’ is requested, then the browser will see that it is a relative URL and automatically make a request for the URL: /WebApplication1/(bcgmybvma1y45czof4me3sq4)/WebForm2.aspx Hence the request header that the browser would send would be:

Here it is very important to note that cookie-less session handling would only work with relative URL’s . If the URL given in an absolute URL from the root, then the request would go as a fresh request and another session would be generated for it. For e.g. consider the following URL on a page:

As we can see, the session ID is a new one, different from one for WebForm1.aspx. Hence URL encoding/mangling cannot be used with full-path URL’s..

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.