2.5 Session Management

2.5.1 HTTP -- a stateless(G) protocol

HTTP is a stateless protocol. That means each HTTP request can be treated as a "new" request with no relations to previous requests. The servers doesn't have to keep any information about previous requests from the client or any session information at all. The advantage of this design is that no session information has to be kept at the server. This allows simple and fast servers.

To implement client-server applications that are more complex and therefore need session information, the client has to send at least a session identification to the server with every request.

2.5.2 Keep the state

If a server application, for example a CGI program, needs to keep and manage state information, for example a session, it has to get the complete state information with every request or map an incoming request to a session. So the client has to transmit all state data or a state ID with every request.

There are several possibilities to achieve that :

2.5.2.1 HTML Forms

A browser sends all data of a HTML form with a POST or GET request. The server sends a form including state data stored in hidden form fields. Hidden form fields are not visible in the browser, but can be seen in the source HTML code. Normally this information will not be altered and just sent back to the server with every POST or GET of the form. A problem lies within the fact that an experienced user can alter the information.

2.5.2.2 HTML links

It is also possible to generate links in HTML documents containing a state ID. This could simply be attached to the request URL on every GET request. In contrast to the HTML forms, this works with every kind of link in an HTML page.

2.5.2.3 Cookies

Another possibility to store state information is a concept called cookies, invented by Netscape in 1995. Cookies are a possibility for the server to store state information on the client side.

The server stores small text fields (cookies) at the browser by sending them in the header of a response. Afterwards, the browser sends them in the HTTP header of every request to the server. A cookie has additional information like a validity period, domain information describing the scope of the cookie on the website, etc. The browser processes this information to decide which cookies to send with which request. If the client gets a newer cookie with the same name from the same server, the old one is replaced.

Cookies can be used to collect user data and to create detailed profiles of the user. For example using the information gathered using cookies one can keep track on where a user surfs in the Internet and in what he is interested in. That is the reason why cookies are often criticized.

"The state object is called a cookie, for no compelling reason." (Netscape Cookie Specification)

2.5.2.4 Java applet / JavaScript

The server can send a Java applet or a JavaScript program to the browser which executes this program. Such a program can then store the state information and communicate via POST or GET or even with an arbitrary protocol with a program at the server machine.

However, the client browser must support execution of java or script code. Many users don't like to execute java applets or script code on their machine, since they could be dangerous if the source cannot be trusted.