by Evangelos Petroutsos
In Chapter 6 where we described the various properties of the document object, we mentioned briefly the cookie property, which lets you store information about your Web site on the client computer and recall it in a later session, or from within another page. The topic of cookies in Internet Explorer 3.0 deserves special attention, and we devote a separate chapter to it. This is another technique traditionally implemented on the server and so far required special software on the server, but now you can implement cookies on the client computer with the help of the cookie property of the document Object. Like image maps, it's another technique that moves from the server to client, simplifying the development of custom Webs.
The term cookie, another UNIX term if you're wondering, is a string, or token, which is contained in the document itself and which the browser can save on the local disk when a page is loaded. This token can be later retrieved by another page of the same Web. The cookie belongs to the Web, and each Web can leave its own cookies on the client computer. Every page belonging to the same Web will be able to access the cookie on the client computer. The next time the client connects to the same Web site, the home and other pages of the Web can read the cookie stored on the local computer during the previous session. This string may contain customization information, which may be as simple as setting the appearance of the page (background/text colors, favorite fonts, and so on), or a description of the action the viewer has taken in a previous section. For example, you can keep track of the software each user has downloaded from your site, or the ads they have already seen, so that the page can display a different ad every time it's opened by the particular client. You can store information about the user's interests in the cookie, and then use it to display relevant ads.
If you don't know how cookies work, or you want to see them in action, you should probably start by visiting a site that supports cookies and familiarize yourself with the possibilities. One such site is Microsoft's MSN page, at www.msn.com. Visit that site and click the Customize Start Page button area to go through the steps of customizing your start page. Figures 14.1 and 14.2 show the generic start page on www.msn.com and a customized start page on the same site. The customized page contains graphics that act as hyperlinks to the various topics (news, sports, and so on). Our examples aren't going to be that elaborate, but we'll demonstrate the basic principles of customizing Webs with cookies.
Figure 14.1 : This is what you'll see the first time you visit the MSN site.
Figure 14.2 : The same site shown in Figure 14.1 after it was customized.
To understand how cookies are used and when to use them, let's look at the more traditional customization techniques. The simplest method of providing custom pages, so far, has been to force users to register the first time they hit your site and to log in with a user name and, possibly, a password. The registration information was stored in a database on the server, and each time a viewer came to the Web site, he or she would have to type a user ID and a password. After a CGI application checked the user input against the registration information, it would supply a custom page for the specific viewer. In other words, the server sends out a generic page, prompting the viewer to enter the site as a registered user. This approach is an inconvenience for the user and a significant burden for the server, because all the customization information about the client is stored on the server. The natural place to store customization information is the client computer, because the customization settings apply to the individual computer only. Even if the customization didn't have to take place on the client computer, the settings can be easily transferred to the server, where the custom page can be selected, or even created on-the-fly.
Cookies enable a Web to store information on the client computer. It doesn't have to be customization information, it could be anything (you can't store binary files, of course, but any string can be easily left on the client's disk). But is this safe? Will cookies impair the viewer's computer safety? Some people don't like the idea of browsers leaving information on their local disks. If, as a user, you are concerned about browsers leaving information on your disk without your permission, you can adjust your browser so that it warns you every time a document is about to store a cookie locally. Select the Options command in the View menu and, when the Options dialog box is displayed, click the Advanced tab, which is shown in Figure 14.3. If you check the box "Warn before accepting cookies," the browser won't store any cookies on your hard disk without warning you first. Check this button and then click the OK button to close the Options dialog box.
If you set your system to warn you every time a cookie is about to be written to the local disk, Internet Explorer will issue a warning like the one shown in Figure 14.4. If you don't care about cookies, or if you don't plan to visit the site that's about to leave a cookie on your computer, click the No button to prevent the browser from storing the cookie on your hard disk.
Actually, cookies are no threat for your computer because they are not executable files. Each site's cookies are stored in a separate text file in the Cookies folder under the Windows folder. With the current implementation of client-side cookies, you can trust any site that leaves cookies to your computer. The basic principles of customizing a Web site with cookies are no different than customizing a service with the caller ID technique, which is used quite frequently by mail-order companies. Many companies that provide services to registered users (be it a computer sales company or a chain of pizza delivery places) use caller ID to offer "personalized service" (and cut down on their costs, too). When you call an 800 number to order diskettes, a new computer, or even a pizza, the operator (or the computerized system that handles the phones initially) knows who's calling before the phone is even picked up. He sees your caller ID (which is your telephone number) knows immediately who's calling, your address, even your most recent order. If you can put up with caller ID for the convenience of not having to repeat your name, telephone number, and address every time you order a computer component, or a pizza, you can certainly live with the idea of others leaving a few bytes of information on your computer so that you can view a site you visit frequently through custom pages.
The document object and its properties and methods were discussed in Chapter 6 but we didn't say much about the cookie property there. Using cookies is a bit more complicated than using the other properties of the document object, not to mention that cookies require a server. A document that makes use of cookies can't be tested locally. In other words, you can't double-click its icon and expect to find a cookie on your own hard disk. The cookie will be created only if the document is furnished to the browser by a Web server. We'll discuss shortly the options for testing the examples of this section.
Let's start our discussion with an introduction to the concept of cookies. A cookie is like a tag you receive every time you check in baggage at the airport. When you check in your baggage, it's tagged with a special number, and you get a copy of the tag. When you arrive at your destination, you use the tag to get your baggage back. This tag uniquely identifies your own baggage. For instance, if your itinerary includes stopovers, your baggage will be handled by the airport crews and it will arrive at the same airport as you, where you can pick it up. Even if, by mistake, your baggage is loaded on the wrong plane, it will eventually arrive at the same destination, although not at the same time as you will. When you visit a Web site that needs to identify your site uniquely, it leaves a tag on a unique location on the hard disk. The next time you visit the same site, the pages of the site can check out this tag by looking at the same location. Each Web site has its own tag on the disk and its contents can be read or updated at any time, but by the pages of this site only. Each site has its own tag, stored in a separate file in the same folder as the tags of all other sites. The cookie is nothing more than a tag (with a fancy name). It's created once, and after that it's used every time you connect to the site that placed the cookie there.
If a Web site uses cookies to customize its pages for specific users, its pages look for the tag (cookie) left there during a previous session. If such a cookie is found, the pages customize themselves accordingly. For example, if a cookie with the user's name is found, all pages may display the user's name in a special box. Or, if a cookie with the user's favorite background color is found, all pages assume this background color (by setting the bgColor property of the document object, as discussed in Chapter 6. A cookie is a tag that uniquely identifies the client. Unlike airline tags, a cookie contains more than just a unique ID. It contains the ID, but it also contains other information that all the pages of a Web site are going to share in one session, or between sessions. Another, less obtrusive, use of cookies is to allow pages to exchange information. The current implementation of VBScript (and HTML) doesn't allow two pages to share information. With cookies, it is possible for all the pages of any given Web site to share information. You can think of cookies as global variables with a Web-wide scope.
Finally, there are two types of cookies: temporary cookies, which last for the duration of a single session and which the client computer doesn't remember the next time the user connects to the same server; and persistent cookies, which are actually stored on the local computer and can be retrieved in a future session. Temporary cookies are ideal for sharing information among the pages of a Web, because they are remembered by the browser, and they are not stored on the disk.
The cookie property of the document object accepts a string that consists of a variable and a value pair, similar to HTML attributes. A cookie that sets the color of the page's background to red would be
BackgroundColor = red
BackgoundColor is not a reserved keyword used in conjunction with cookies. You can use any variable name to describe a cookie. When a string like the previous one is assigned to the cookie property of the document object, the browser appends it to the file with the cookies for the current Web. You can append as many strings to the file with the cookies as you need.
The following VBScript lines will create a cookie file with three cookies:
cookie1="USERFNAME=Peter" Document.cookie=cookie1 cookie2="USERLNAME=Evans" Document.cookie=cookie2 cookie3="ZODIAC=Aquarius" Document.cookie=cookie3
Once these lines are executed, a new cookie file will be created on the client computer. (If a cookie for this site exists already, the new values will either replace the existing ones, or append new variables to the existing cookie file.) This is a text file, and you can open it with any text editor to examine its contents. If you open your Windows | Cookies folder, you'll probably find cookies from other Web sites.
Your scripts can read the cookies placed earlier on a client computer by reading the cookie property of the document object. The following VBScript statements read the value of the document's cookie property, assign it to a variable, and then display the value of the variable with the MsgBox() function:
cookie=Document.cookie MsgBox cookie
If these two lines are executed after the lines that set the three cookies of the previous example, the MsgBox() function will report the following string:
BGCOLOR=lightgray; FRCOLOR=blue; LINKS=red
Consecutive pairs of variables/values are separated by a semicolon. Every time a new cookie (variable/value pairs) is created, a new string of the form Variable=Value is appended to the cookie file. When you read the cookie property, though, VBScript returns a long string with all the cookies.
You can test previous lines by placing them in the SCRIPT
section of an HTML document. But the cookie mechanism will work
only if the document is supplied by a server. If you just double-click
an HTML document that contains VBScript lines that set the cookies
property of the document object, VBScript will generate
an error message to the effect that the object doesn't support
the cookies property. The browser on its own can't create
the cookies. The Web server's involvement is required.
| NOTE |
This chapter's projects can't be tested by simply opening them with Internet Explorer. To test the documents that contain cookies, you would need to be supplied by a Web Server, as explained in this section. If you double-click a project's icon to open it with Internet Explorer, the cookies will be blank strings. |
To test the examples of this section on your computer, you must post the document that contains cookies on a Web. There are many ways to post a Web site and we'll present the simpler ones here. The simplest method is to set up your own Web server. You can install the FrontPage Personal Web Server and then place the document you want to test in the Content folder under the FrontPage Web folder and rename it to Index.htm. The FrontPage Personal Web Server is part of the Microsoft FrontPage package, which you can download from Microsoft's Web site. It's a time-bombed version (it will stop working after the last day of 1996, but you can visit this site for updates or a newer beta). To turn your Windows 95 machine into a Web server, all you have to do is run the Personal Web Server program. If you are connected to your Internet service provider when you start the program, other users will be able to access your site. If not, you'll still be able to test your pages locally.
If you are connected to an Internet service provider, you must find the IP address you were assigned when you connected to the Internet service provider's server. Run the WINIPCFG program, which will report your IP address. Open the Start menu, select Run, and in the dialog box that will be displayed type WINIPCFG. The IP address is a group of four numbers separated by periods. Notice that your IP address is different each time you connect to your ISP's server. The IP address reported by the WINPICFG application is valid for the current session, and the next time you connect you must find out your new IP address.
You must copy the document you want to test to the ISP's server. Most ISPs will give their subscribers a folder on their server where users can place their personal home pages. You must contact your ISP to find out where you should store the home page and accompanying documents and your address on the Internet. When you place a Web site on someone else's server, you get a URL such as www.someServer.com/users/~PEvans, where PEvans is your user name. The tilde character is always there and gives away the fact that you are renting space on someone else's server. You can also contact a Web service provider or Web hosting service that will give you all the space you need on a Web server, along with a registered name, such as www.pevans.com. Place the document with the cookie in your folder on the ISP's server and then connect to your own URL.
Finally, you can start Internet Explorer and enter the IP address of your computer in the Address box. If you are not connected to an ISP, you can type the IP address of the local host, which is always 127.0.0.1. When you connect to the address 127.0.0.1, the browser will be served by the Web server running on the local machine. If you are using the FrontPage Personal Web Server on Windows 95, or Internet Information Server on Windows NT, Internet Explorer will connect to the local host without accessing the Internet.
Because Microsoft FrontPage Personal Web Server is available for evaluation purposes for free, we'll use this server in our examples. Again, the other approaches are just as easy. You can use any Web server you may be using right now to test the examples of this chapter locally.
Let's build our first example, which will save a few cookies and their values and then read them. This example, shown in Figure 14.5, is called Cookies1.htm, and you will find it on the CD. It sets three cookies and reads their values, with the following code:
<HTML> <HEAD> <TITLE>Cookies Demo 1</TITLE> <SCRIPT LANGUAGE="VBS"> Document.write "<CENTER><H1>Testing Cookies</H1></CENTER>" cookie1="USERFNAME=Peter" Document.cookie=cookie1 cookie2="USERLNAME=Evans" Document.cookie=cookie2 cookie3="ZODIAC=Aquarius" Document.cookie=cookie3 MsgBox "Cookies set. Click OK to read their values" cookie=Document.cookie msgbox cookie </SCRIPT> </HEAD> <BODY> </BODY> </HTML>
The VBScript code segment of this document sets the values of three cookies and then displays a message to inform the viewer that the cookies are set. Then, it reads their values and displays them in a dialog box. To test this application, copy the Cookies1.htm file in the Web's Root folder and rename it to Index.htm. (If your server is the Internet Information Server, rename it to Default.htm.) Then start Internet Explorer and connect to the Web server. If you are testing the cookies locally, connect to the IP address 127.0.0.1.
The first conclusion you can draw from this simple project is that, before you can use the cookies in your code, you must first extract them from the cookie property. Whereas individual cookies can be stored one at a time, you can't read a specific cookie, just the string that contains all of them. This takes a bit of code. We'll see shortly how this is done, but first let's explore the cookie property of the document object a little further.
Open the Cookie1.htm file (or Index.htm file if you've renamed it on the server) and change the value of one of the cookies. For example, change the value of the ZODIAC variable from Aquarius to Sagittarius:
cookie3="ZODIAC=Sagittarius"
Then, add a new cookie with the statements:
cookie4="MESSAGE=We've been here before" Document.cookie=cookie4
If you refresh the current document in Internet Explorer, the new value of the document's cookie property will be
USERFNAME=Peter;USEFLNAME=Evans;ZODIAC=Sagittarius;MESSAGE=We've been here before
There are two items worth noticing here. VBScript didn't create a new ZODIAC cookie. Instead, it replaced the value of the existing cookie. That was very nice, because we won't have to manipulate the strings ourselves every time we want to modify the value of a cookie. The other item is that the new cookie was appended at the end of the existing string.
Storing and recalling cookies on the client computer is as easy as setting, or reading, the value of the cookie property of the document object. Even if you are using the same computer as server and client, nothing changes. The browser doesn't even know that it's being served by the same computer. The next question should be "where are the cookies, and what do they look like?"
The cookies you've created so far aren't stored on the local disk. To make a cookie persistent, you must append the string
;expires=<date>
to the cookie. <date> is an expression like Wed, 01 Jan 1997 12:00:00 GMT, which specifies when the cookie expires. If you don't specify the expiration date, the cookie expires at the session's end. The expires option makes the cookie persistent, which means it's saved on the local disk, in the Cookies folder under the Windows folder.
As we mentioned already, cookies are saved in text files in the Windows | Cookies folder. Each Web's cookies are stored in a single file, and the name of the file is your domain name. For an account name like pevans@sams.com, the cookie file's name would be pevans@sams. If you are connecting to the local host IP address, the cookie file will be named anyuser@127_0_0_1 (it may be truncated, too). anyuser is a literal string, and it doesn't stand for a user name. Each Web site has a unique name which is used to create a unique cookie file on the client, so that all the pages belonging to the specific Web will access the same cookie file. The anyuser@msn, for instance, contains the cookies left on your system by the MSN site.
If you open the cookie file you just created with WordPad, you'll see something like the window of Figure 14.6. It contains the cookie names and their values on separate lines and a bunch of numbers inserted there by the browser, which you can safely ignore. The expiration date is stored there somewhere, but not in a way that is easy to see or tamper with. As you can see from the title of the document, it was tested locally with the FrontPage Personal Web Server.
Figure 14.6 : The contents of the cookie file generated by the Cookie1 project.
Now delete the cookie file. Right-click its icon and, from the Shortcut menu, select Delete. Then modify the document by deleting the lines that set the cookies (all the lines that begin with Document.cookie=) and the line with the first call to the MsgBox() function. Even better, comment out these lines and then save the Index.htm file again. Then return to your browser and refresh the current document (or open it again). The script will report the same cookies! You can visit other sites and then return to yours. The cookies will still be there. If the file is deleted, how does the browser know the values of the cookies? These values were cached when the page was first opened, and they will persist for the duration of the session. If you close Internet Explorer and then start it again and connect to the same host (most likely the local host), the values of the cookies will be lost. This time, the MsgBox function will report a blank string.
In order to use the cookies you have left on the client site during a previous session, you must read the cookie property of the document from within your code and extract the individual cookie values. The code for extracting each individual cookie is straightforward. Any way you implement it, this code makes extensive use of the string manipulation functions to isolate cookies and their values. The ReadCookies page (which can be found on this chapter's folder on the CD) contains a function that does exactly that. You can use this function as a starting point, or implement a different one, but the basic idea is to scan the entire cookie, locate pairs of variables and values, and extract them.
Figure 14.7 shows the Cookie2 document, which sets a few cookie values and then reads them from another page. Because both pages belong to the same Web, they can both access the same cookies. The first page creates the cookie; the second page reads them.
Figure 14.7 : The first page of the Cookie2 Web creates a few persistent cookies.
For a clean start, delete the cookies file from the folder Windows | Cookies and shut down Internet Explorer if it's running. Then copy the document CookiePage (in the Cookies folder on the CD) to the Web's root directory, rename it to Index.htm, and start Internet Explorer to connect to your host. The first time you connect to your server and the home page is displayed, you'll see a generic page, like the one in Figure 14.7. The second page of the cookie document is shown in Figure 14.8. This page can read the value of an individual cookie, or display all the cookies on a separate page, as shown in Figure 14.9.
Figure 14.8 : The page Cookie2a is the second page of the Cookie2 document.
Figure 14.9 : This page extracts and displays all the cookies of the site.
Now click the various buttons to create a few cookies. The program will prompt you to enter the values of certain settings with an InputBox, like the one shown in Figure 14.10. We used the InputBox function to simplify the code on the page. In a real-world application, you should design a good-looking page to obtain user input with the ActiveX controls discussed in the previous chapters.
After all the cookie values have been set, the script will save the cookies on the local computer. Now click on the hyperlink on this page to switch to another page (shown in Figure 14.8) of the same Web. This page can access the cookies stored by the Web's home page. You can click the first Command button to find out the value of an existing cookie, or click the second Command button to see all the cookie values stored on the client computer by the home page.
When the first Command button is clicked, the code will prompt the user to enter the name of the variable he or she is interested in. Then it will retrieve the cookie, locate the value, and display it in a Message box. The second Command button reads the cookie, extracts all the variables and their values and displays them on a separate page, with the write method of the document object. The two useful procedures in this application are a function that finds the value of a variable in the cookie and a subroutine that scans the cookie and reports all the variables stored in it and their values.
Listing 14.1 shows the code of the Cookie2 page.
Listing 14.1. The Cookie2 page.
1: <HTML>
2: <HEAD>
3: <TITLE>Setting and Reading Cookies</TITLE>
4: <SCRIPT LANGUAGE="VBS">
5: Sub Button1_onClick()
6: bg=InputBox("Enter your favorite background color")
7: cookie1="BGCOLOR=" & bg
8: Document.cookie=cookie1
9: End Sub
10: Sub Button2_onClick()
11: fg=InputBox("Enter your favorite foreground color")
12: cookie2="FRCOLOR=" & fg
13: Document.cookie=cookie2
14: End Sub
15: Sub Button3_onClick()
16: msg=InputBox("Enter a personal message")
17: cookie3="MESSAGE=" & msg & ";expires=Wed, 01 Jan 1997 12:00:00 GMT"
18: Document.cookie=cookie3
19: End Sub
20: Sub Button4_onClick()
21: cookie=Document.cookie
22: msgbox cookie
23: End Sub
24: </SCRIPT>
25: </HEAD>
26: <BODY>
27: <CENTER>
28: <H1>Setting and Reading Cookies with VBScript</H1>
29: <INPUT TYPE="BUTTON" NAME="Button1" VALUE="Set bgColor">
30: <INPUT TYPE="BUTTON" NAME="Button2" VALUE="Set fgColor">
31: <INPUT TYPE="BUTTON" NAME="Button3" VALUE="Set Message">
32: <INPUT TYPE="BUTTON" NAME="Button4" VALUE="Read Cookies">
33: <BR><BR>
34: <H4>Click <A HREF=index2.htm>here</A> to read the cookies from another page
</H4>
35: </CENTER>
36: </BODY>
37: </HTML>
The first three Command buttons on this page create three variables and store them in the cookie. The names of the variables are FGCOLOR, BGCOLOR, and MESSAGE. Their values are specified by the user with the help of an InputBox() function. You can set the value of each cookie as many times as you want, and the cookie property isn't going to create additional variables. Each time a new value is assigned to an existing variable, it replaces the existing value and does not create a new variable.
The destination of the hyperlink is the Index2.htm file, whose contents are shown in Listing 14.2.
Listing 14.2. The Index2.htm file.
1: <HTML>
2: <HEAD>
3: <TITLE>Setting and Reading Cookies</TITLE>
4: <HEAD>
5: <SCRIPT LANGUAGE=VBS>
6: Dim cookies(2,50)
7:
8: Function GetCookie(whichVariable)
9: cookie=Document.Cookie
10: VarPosition=Instr(cookie, whichVariable)
11: If VarPosition=0 then
12: GetCookie=0
13: Exit Function
14: Else
15: StartVarPosition=VarPosition+Len(whichVariable)
16: EndVarPosition=Instr(StartVarPosition, cookie, ";")
17: If EndVarPosition=0 then EndVarPosition=Len(cookie)+1
18: GetCookie=Mid(cookie, StartVarPosition, EndVarPosition-
StartVarPosition)
19: End If
20: End Function
21:
22: Sub CButton1_onClick()
23: ckVar=InputBox("Enter the name of the cookie")
24: If ckVar<>"" Then
25: ckVal=GetCookie(ckVar)
26: End If
27: If ckVal<>"" Then
28: msgbox "The value of the " & ckVar & cookie & " is " & ckVal
29: Else
30: msgbox "No " & ckVar & "cookie found"
31: End If
32: End Sub
33:
34: Sub CButton2_onClick()
35: cookie=Document.cookie
36: i=1
37: While len(cookie)>0
38: pos=Instr(cookie, "=")
39: If pos>0 then
40: ckVar=left(cookie, pos-1)
41: cookie=mid(cookie,pos+1)
42: pos=Instr(cookie,";")
43: If pos=0 then
44: ckVal=cookie
45: cookie=""
46: Else
47: ckVal=left(cookie,pos-1)
48: cookie=mid(cookie, pos+1)
49: End If
50: cookies(1,i)=ckVar
51: cookies(2,i)=ckVal
52: End If
53: i=i+1
54: Wend
55: ncookies=i-1
56:
57: Document.open
58: Document.write "There were " & ncookies & " cookies in the document"
59: Document.write "<TABLE>"
60: For ck=1 to ncookies
61: ckvar=cookies(1,ck)
62: ckval=cookies(2,ck)
63: Document.write "<TR>"
64: Document.write "<TD>" & ckvar & "<TD>" & ckval
65: Document.write "</TR>"
66: Next
67: Document.write "</TABLE>"
68: Document.close
69: End Sub
70: </SCRIPT>
71: <BR><BR>
72: <INPUT TYPE=BUTTON NAME=CButton1 VALUE="Show A cookie">
73: <INPUT TYPE=BUTTON NAME=CButton2 VALUE="Show All cookies">
74: <A HREF=index.htm>Back to previous page</A>
75: </BODY>
76: </HTML>
The GetCookie() function accepts the name of the cookie to extract as argument and extracts it from the Document.cookie property. First, it locates the variable's name in the cookie, and then it looks for the following semicolon. When GetCookie() finds the variable, it has in effect located the value following the variable name and returns it to the calling function. VarPosition is the position of the variable name in the cookie. After the variable name is found, the function looks in the rest of the cookie to find the following semicolon, which signals the end of the cookie's value (or the end of the string, if it happens to be the last cookie in the string). The StartVarPosition and EndVarPosition variables delimit the cookie's value in the string, and they are used to extract it.
The CButton2_onClick() subroutine works in a very similar manner. It starts at the left end of the string and treats everything to the first equal sign as the variable name. Then it locates the following semicolon, and everything between the equal sign and the semicolon is the value of the variable. With the first variable/value pair out of the way, it truncates the cookie by removing everything from the left up to (and including) the semicolon, and it repeats the same process over and over until the entire cookie has been searched.
The customization techniques you learned in this chapter rely on the document itself and the browser. To create a highly customizable Web, like the MSN Web site for example, you must do some programming on the server. Let's say you have a number of home pages, each one for a specific category of users-a page for sports fans, another one for music lovers, another one for computer game addicts, and so on. To display the appropriate page to every client who has customized his or her home page, prepare a starting page with no content, or a simple design that informs the user that his or her custom page is being downloaded. This generic page should contain the VBScript code for grabbing the values of the cookies, place them in a hidden TextBox control, and then submit them to the server with the Form's Submit method. Or decide which of the many start pages suits the user's interest the best and request that page. If the cookie contains the string sports, the CustomSports page should be loaded. One way to do this is via the href property of the document's location object.
A customized site such as the MSN site uses a CGI application that creates the custom home page on-the-fly. Again, you can start with a generic home page, which reads the value of the cookie with all the settings, stores them in a hidden TextBox, and submits its contents to the server. The server will then generate a new home page on-the-fly, based on the viewer's preferences. There's quite a bit of overhead with this approach, because generating good-looking pages programmatically requires good programming skills and creativity. To simplify the task of setting up a custom page, you can use frames, some of which will be the same on all pages and the remaining ones will contain customized content. Frames will help you organize the information you want to place on the pages, without having to worry about sizing the pages and the positioning of the elements on them. The users will decide how big each frame will be.
The last approach of combining cookies and CGI applications to customize your Web is the most flexible approach, but the most demanding one in terms of authoring. If your goal, however, is to attract users to your site, this is the extra step that will place your site ahead of the others. You can also use this technique quite efficiently in an intranet environment to provide custom pages to certain groups of users. The users in the marketing department, for instance, will see the Marketing.htm page every time they start Internet Explorer, and users in the accounting department will see the Accounting.htm page.