HTTP

State & Session Management

Introduction

HTTP is a stateless (or non-persistent) protocol. Each request is treated by its own. A request will not know what was done in the previous requests. The protocol is designed to be stateless for simplicity.  However, some Internet applications, such as e-commerce shopping cart, require the state information to be passed one request to the next. Since the protocol is stateless, it is the responsibility of the application to maintain state information within their application.

A few techniques can be used to maintain state information across multiple HTTP requests, namely,

  1. Cookie
  2. Hidden fields of the HTML form.
  3. URL rewriting.

Cookies

HTTP is a stateless protocol. That is, the server does not hold any information on previous requests sent by the client. Client-side cookies were introduced by Netscape to maintain state, by storing client-specific information on the client's machine and later retrieved to obtain the state information. Montulli, the creator of cookie from Netscape, chose the term "cookie" as "a cookie is a well-known computer science term that is used when describing an opaque piece of data held by an intermediary".  The term opaque here implies that the content is of interest and relevance only to the server and not the client.

A cookie is a small piece of information that a server sends to a browser and stored inside the browser.  The browser will automatically include the cookie in all its subsequent requests to the originating host of the cookie.  Take note that cookies are only sent back by the browser to their originating host and not any other hosts. In this way, the server can uniquely identify a client (or a browser).

A cookie has a name and a value, and other attribute such as domain and path, expiration date, version number, and comments.  Domain and path specifies which server (and path) to return the cookie.  Cookie could be persistent (with a future expiration date) or last only for that particular browser’s session (i.e., removed when you close the browser).  A web browser is only required to accept up to 20 cookies per server and 300 cookies in total.  Each cookie is limited to 4 KB.

A server can set the cookie's value to uniquely identify a client. Hence, cookies are commonly used for session and user management. Cookie can be used to hold personalized information, or to help in on-line sales/service (e.g. shopping cart), or tracking popular links, or for demographics purpose.

The main limitation of using cookie for tracking is users may disable cookie in their browser.

There are 2 versions of cookie specifications. Version 0 is specified by Netscape, while version 1 is specified in "RFC2965 and RFC 2109: HTTP State Management Mechanism".

"Set-Cookie" Response Header

A cookie is created when a client visits a site for the first time. A server-side program sends a response message containing a "Set-Cookie" response header. The header contains a name/value pair of the cookie plus some additional information.

Cookie Version 0 "Set-Cookie" Header (Netscape)
Set-Cookie: cookie-name=cookie-value; expires=date; path=path-name; domain=domain-name; secure

For Example:

Set-Cookie: cookie1=111; Expires=Sat, 21-Feb-2004 05:04:54 GMT
Cookie Version 1 "Set-Cookie" Header (RFC2109/RFC2965)
Set-Cookie: cookie-name=cookie-value; Comment=text; Domain=domain-name; Path=path-name; Max-Age=seconds; Version=1; Secure

RFC2965 define a new header "Set-Cookie2", which might not be widely supported by browsers, as follows:

Set-Cookie2: cookie-name=cookie-value; Comment=text; CommentURL=url; 
  Domain=domain-name; Path=path-name; Max-Age=seconds; Port=port-list; Version=1; Secure

"Cookie" Request Header

The client returns the cookie(s) to the matching domain and path in the subsequent requests, using a "Cookie" request header.

Cookie: cookie-name-1=cookie-value-1; cookie-name-2=cookie-value-2; ...

Trace of Non-persistent Cookies

Client 
GET /test/servlet/CookieTest HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Host: 127.0.0.1:8000
Connection: Keep-Alive
Server 
HTTP/1.1 200 OK
Set-Cookie: cookie1=11111111
Content-Type: text/html;charset=ISO-8859-1
Content-Length: 156
Date: Sun, 08 Feb 2004 16:23:13 GMT
Server: Apache-Coyote/1.1
   
(response message body omitted)
Client 
GET /test/servlet/CookieTest HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Host: 127.0.0.1:8000
Connection:    Keep-Alive
Cookie: cookie1=11111111
Server 
HTTP/1.1 200 OK
Set-Cookie: cookie2=22222222 
Content-Type: text/html;charset=ISO-8859-1
Content-Length: 156
Date: Sun, 08 Feb 2004 16:23:13 GMT
Server: Apache-Coyote/1.1
   
(response message body omitted)
Client 
GET /test/servlet/CookieTest HTTP/1.1
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Host: 127.0.0.1:8000
Connection: Keep-Alive
Cookie: cookie1=11111111; cookie2=22222222

Trace of Persistent Cookies

Client 
GET /cookie/servlet/TestCookieClass HTTP/1.1
Accept: image/gif, image/jpeg, */*
Accept-Language: en-us
Accept-Encoding: gzip, deflate
User-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1)
Host: 127.0.0.1:8000
Connection: Keep-Alive
Server 
HTTP/1.1 200 OK
Set-Cookie: cc4=4444; Expires=Tue, 10-Feb-2004 18:32:03 GMT
Content-Type: text/html; charset=ISO-8859-1
Content-Length: 550
Date: Tue, 10 Feb 2004 04:38:43 GMT
Server: Apache-Coyote/1.1 
   
(response message body omitted)

The cookie file contains the following:

cc4
4444
127.0.0.1/cookie/servlet/
1024
762958720
29618180
3279392352
29618063
*
 
Name
Value
Matching domain and path
??
??
??
??
??
Cookie separator

Security and Privacy Issues

HTTP Session Management

The following techniques can be used for HTTP session management:

  1. Cookies
  2. URL rewriting
  3. Hidden fields in HTML form.

Cookie

Most often cookie is used to store a session ID. The session management is done at the server side, instead of client side.

For example, the following Java servlet uses cookie for managing session ID:

HashTable allSessions = new HashTable();
...
String sessionID = getUniqueSessionID();
HashTable sessionData = new HashTable();
allSessions.put(sessionID, sessionData);
Cookie sessionCookie = new Cookie("sessionID", sessionID);
sessionCookie.setPath("/");
response.addCookie(sessionCookie);

The problem on using cookie is some users disable cookie due to the real and perceived privacy concerns over cookies.

Hidden Field in the HTML Form

The principle is to include an HTML form with a hidden field containing a session ID in all the HTML pages sent to the client.  This hidden field will be returned back to the server in the request.  No cookie needed. The disadvantage of this approach is it requires careful and tedious programming effort, as all the pages have to be dynamically generated to include this hidden field.  The advantage is all browser supports HTML form.

<form method="post" action="url">
  <input type="hidden" name="sessionid" value="1111">
  ...
  <input type="submit">
</form>

URL rewriting

The principle is to include a unique session ID in all the URLs issued by the client, which identifies the session. For example,

http://host:port/shopping.html;sessionid=value

To accomplish this objective, you must rewrite all the URLs in all the HTML files that is send to the client with this unique session ID (such as <a href='url'>, <form action='url'> etc.).  Again, careful and tedious programming efforts are required.  The advantage is all browser supports URL rewriting. URL rewriting works even if the browsers do not support cookies or the user disables cookies.

Examples

Java Servlet: Read ....

 

REFERENCES & RESOURCES

Latest version tested: Apache HTTP Server 2.2.14
Last modified: October 20, 2009