On the Web, with previous applications based on technologies such as CGI, the problem has always been that, when a client submits a request, the server just produces a response and returns it. When another request is received from that user, the server has no idea if there was a previous request. This is because the HTTP protocol is stateless. Building client/server programs with a stateless protocol can become very complicated.
To understand why, imagine building a traditional application in, say, Visual Basic. You design a form with a dozen or so command buttons, and write a piece of code that runs when each button is clicked. VB itself knows which button was clicked, and so runs the correct code routine for that button. But now imagine that VB was designed like HTTP. Instead of running individual routines for each button, you would have only a single block of code. VB would run this code when any of the buttons is clicked, without telling you which one it was. You can see how this would, to say the least, make building applications difficult.
To get around this problem Netscape developed the concept of a cookie. A cookie is purely a small informational text string that is stored on the user's hard disk—we looked at them in some depth back in Chapter 2.
Many people worry that cookies can be dangerous. While they can be used in all kinds of ways by server-based application, they pose no risk to you as a user. Cookies, as they are documented, will not format your disk, send back information about your system, or put you on a mailing list. Unfortunately they don't make the coffee either.
Typically, when the client makes a request for a document from a specific virtual directory on a server (which can include the
directory), the server returns a cookie—or token of information. When the user returns to the same virtual directory, or one of its subdirectories the browser sends that cookie back, as part of the HTTP request. wwwroot
If we were building CGI-based applications, we would use the cookie information to check who the user was and collect other information regarding their interaction with our application. Working with cookies directly can be fun and interesting for about 30 seconds, and until you realize that you need to go home by five o'clock. As we saw in Chapter 2, ASP does make the task a lot easier through the
collections of the Cookies
and Request
objects.Response
However, the big advantage that the Active Server Pages framework provides is an automatic mechanism for maintaining state in our applications, without having to directly manipulate cookies ourselves—although ASP requires the browser to support and accept cookies in order to function properly. If the user refuses to accept cookies through settings in their browser's security options, or if their browser doesn't support cookies, this automated mechanism will fail.