8.1.1- Tracking Users

Tracking Users

If you are using a traditional desktop application, like Microsoft Word for example, you start up the application and open a file to edit. You can continue to make changes to the file until you save and close it. Each change you make is recorded into the file, whether you are adding new text or deleting existing text. The time period during which you are editing this file can be thought of as a session.

There is a connection between you – the user – and the file. All of your edits go to that file (that is, unless you switch to a different file). You do not have to tell Microsoft Word each time that you make a change which file you are editing, because the application maintains information about your current editing session.

Things are different on the web. In contrast to the way that traditional applications work, on the web the relationship between the client and the server is said to be stateless. In a stateless environment, the server does not track a client from request to request. HTTP is a client driven protocol, the client tells the server what it wants, and has to get an answer in the same connection. It's like writing a letter, then sending it; if you forget to put something in that letter, then that's too bad – you'll have to mail another letter with that separate request in.

The web server that runs the HTTP service basically sits there and waits for a request to come in. Typically a client will connect and make a request – the web server will then process the request and send back an answer to the client. The web server cannot determine whether this client has made any previous connections before, or has a past history. So, if you want to keep track of a user, then HTTP on its own is not suitable for the task, since it's not capable of storing this kind of information. Each request that comes in from a client is treated as if the server knows nothing about the client. There is no memory of previous connections between the client and server.

For serving up standard web pages, this is an ideal situation. Using HTTP, a web server can handle a large number of simultaneous requests for pages. It can also handle them quickly, the advantage of HTTP being that because the server never has to maintain a history for each request, the server can just concern itself with providing pages as fast as possible. It also does not have to worry about what a client did previously before it sends a page. Unfortunately, this can make writing applications very difficult.

Let's consider an example where a user logs on to an e-commerce site that sells books. The user starts on the home page of the site, and then gets asked to log in. Once they've logged on, they're directed to a customized home page that will hopefully show a range of books of particular interest to that user, such as new books by their favorite authors etc. They'll want to be able to browse a catalog of items, and from that catalog be able to select items to buy, and place in the shopping basket. This would make a total of at least five separate pages that the user would be navigating through. It would be ideal to maintain some kind of state for the entire time the user is logged in. The diagram below illustrates this:

Firstly, you'd want only the user to be able see information about their own choices and own shopping basket. So you'd need to track a user id and password over several of the pages. Also when the user selects an item from the catalog, you'd need to be able to add it to the shopping basket, along with the quantity of the item selected. Then from the shopping basket you'd want to be able to return and continue browsing the catalog, possibly making further selections and adding to your shopping baskets, as you jumped between the two pages. Finally, it would be nice if the whole site was customized to your particular browser wouldn't it?

So, for both the user and for the people who wrote the application, the one request per connection can be more than a little frustrating. The good news is that ASP introduces several aids to the developer for tracking users. However the first one outdates ASP itself, and is known as a cookie. Cookies are used to solve the problem of web sites using an anonymous protocol system.