Front Page Perl Education Perl Education Articles

Introduction

If you're trying to create any type of interactive web site -- such as an e-commerce shopping site -- you'll quickly run into a problem known as state maintenance. In short, this means that when a user moves from one page to another on your web site, you need to know what they've already purchased or viewed -- but you can't -- unless you manually maintain some type of state information as the user moves around.

In this article, we'll discuss how you can maintain state information in your Perl/CGI programs by using "cookies" in your CGI programs. Cookies are one way -- maybe the best way -- of maintaining state information as a user moves around your web site.
 

The problem of state maintenance

As you may know, HTTP is a stateless communications protocol. This means that when a user moves from one page to another on your web site, no information is passed between the pages. Well, if you can't pass information from one page to the next as a user moves through your web site, how will you ever know what they're trying to buy?

The answer is "you can't", unless you implement some means of state maintenance, i.e., the art of maintaining information as a user moves from one page to another on your web site.
 

State maintenance options

Currently, there are several ways of maintaining state information. These methods are:

1. Using "cookies".
2. Embedding query strings in your URLs.
3. Using hidden form variables in your HTML pages.

What's a cookie?

In web lingo, the term "cookie" or "cookies" refers to information that you can store on a client's computer for later retrieval. Yes, that 's right, cookies let you write information to the disk drives of your visitor's computer. (As you'll see however, the amount of information you can write is limited.)

Basically, you store information on a visitor's computer in the form of "name=value" pairs. For instance, you can save information like this on your visitor's computer:

SHOPPER_ID=10001

Cookies also let you set other information. In your programs you can set and retrieve the following information for each cookie:

1. The name=value information mentioned above.
2. The cookie's expiration date and time.
3. The domain where the cookie is valid.
4. The path on your server where the cookie should be applied.
5. Whether a cookie should only be used on a secure channel.

While it's very easy to set more than one cookie on a visitor's computer, in the real world it seems that most web sites store only one or two cookies at most.
 

Drawbacks of cookies

Before, diving right in, there are several potential pitfalls when using cookies that you need to be aware of:

1. Visitor's can configure their browsers to disallow cookies.
2. Cookie information is stored in plain text files on the user's computer.
3. The cookie file can be deleted or write-protected (usually accidentally).
4. Cookies are associated with a browser (Netscape Navigator stores it's cookies in one location, while Microsoft Explorer puts their cookies in another location), so if a user switches from one browser to another, the cookie information will not be shared between the browsers.
5. If multiple people use the same computer and browser, they can end up using somebody else's cookie information.
6. Not all browsers support cookies (this is not too much of an issue any more, because cookies are now supported by Navigator 2.x  and Explorer 3.x and newer).

When cookies were first designed by Netscape, many users were very reluctant to allow web sites to store information on their hard drives. Now, several years later, this technique is used by many sites and user's fears seem to have subsided.
 

Other cookie restrictions

If writing information to the hard disk drives of your visitor's sounds interesting, consider the following restrictions:

1. Number of cookies that can be stored per server or domain: 20
2. Total cookies per browser: 300
3. Largest possible cookie: 4 KB

As a final note, cookies can only be viewed from web servers in the domain from which they were defined. This is a security precaution that keeps one domain from seeing cookie information from other domains. This means that you cannot see cookie information from yahoo.com or aol.com, and they cannot see your information.
 

How to use cookies

Now that I've given you all the warnings and information I can think of, let's talk about how you can use cookies in your Perl/CGI programs. For this discussion, let's consider two cases: (a) a shopping-cart application, and (b) a user-customizable web site.

(a) A shopping cart application

When a user first enters your shopping cart area, you'll probably want to use these steps in your CGI program:
 
1. Test to see if the desired cookie has already been set.
2. If the cookie is already set, you can (a) use the old cookie value or (b) create a new value for the same cookie (for instance, you may want to change the expiration date of the cookie).
3. If the cookie has not been set, you should set it now.

Now, once the cookie is set when the user first enters your shopping cart area, you can implement one of two possible approaches:
 

1. Just assign a "SHOPPER_ID" number in the cookie, and keep the purchase information in a database on your server, or
2. Try to keep all the purchase information in the cookie.

Because of the size limitations on cookies, most sites seems to use the first option. If you take this approach, all you need to do throughout the remainder of your application is retrieve the SHOPPER_ID, and use it to retrieve data in your shopping cart application. There's usually no need to re-set the cookie later in your application.

(b) A customized web site area

In our second example, consider a web site whose appearance can be customized by each visitor. One user named Fred might come to this site and make his background blue and his text yellow, while another user named Joe might want his background black and his text white.

These are just two characteristics they can customize. Suppose the site is a real high-powered information site where the user can also set the font type, font size, the up-to-the-minute stock market information that should appear (i.e., display stock prices for Sun, Microsoft, and Yahoo), what news items should appear (sports, weather), etc. As you can imagine, this can lead to a very large number of customizable variables.

If I had a small web site, I might be tempted to set a simple cookie like this:
 

BG_COLOR=blue&FG_COLOR=yellow

or maybe store the same information in two separate cookies like this:
 

BG_COLOR=blue
FG_COLOR=yellow

But, if the site was going to become very large at all, I would probably just set a user id variable like this:
 

USER_ID=100021

and then maintain all of the user preferences in a database. Otherwise the cookie may get too large or you may start saving a large number of individual cookies. (Please note that this is just my opinion; I suggest doing whatever you think is best in your application.)

To be continued ...

Well, that's probably a lot of information to consider, so we'll pause here for a short break.

We'll follow this article very shortly with some working Perl/CGI code that you can use in your own programs. In Part 2, we'll show you (a) how to set and (b) how to retrieve cookie information in your Perl programs. We'll use the CGI.pm Perl module for all of this, because, hey, it's the easiest way.
 
 [an error occurred while processing this directive]