Persistent Client Side Data Using Cookies

You are going to like this next example. It shows the reason that ADO is the wave of the future.

On the Internet, when you request a web page using Hyper Text Transfer Protocol (http), this connection is known as 'stateless'. When you request a web page, a connection is opened, the HTML code is downloaded to your browser, and the connection is closed. The server has no memory of you being there. It just served the HTML page to the client browser and then went about its business. If you came back to that server, it had no idea if this was your first visit or your twentieth.

There has got to be some way for the server to 'remember' if you were there. Why? Well consider some of the surveys you fill out to gain access to a site. You fill out the text boxes, get registered, and the next time you log in the survey is bypassed. It's a good thing too, because if you had to fill out the survey every time you logged in to the site, you would never go back.

There is also the notion of 1 to 1 marketing. Let's say that my web site sells a new product called an Oscillating Overthruster as an aid to entering the 8th dimension. Well, if you ordered one from my site, the next time you return I might want to display accessories for the product, or notify you of version 2.0 that is much better. I can tailor the HTML page for an individual user.

But wait. How can this be done after we just discussed the statelessness of each and every HTTP connection? Well, we can easily accomplish this by using what is known as a cookie. What are cookies? Essentially, they are just simple text files that can be written to the user's hard drive by the server. So when you download an HTML page, there can be a command right in the page that writes the cookie file to your PC. It can contain any information the server wishes to place in it. And then it can be read the next time you log in to that server. So the server could take your response to a survey and when you successfully complete it, a cookie with a unique identifier is written to your PC. The next time you log in to that site, the HTML page that is downloaded to your PC looks for a cookie. If it finds it, the unique identifier is read and the server knows you have already responded to the survey, so the survey process is bypassed. If no cookie is found, it assumes you are new and presents the survey before you can move on.

Cookies written by a server to your machine can only be read by that self-same server.

All right. Lets' say that we build a web site where we wish to track each and every visitor. The first time the surfer logs in, we ask for the Big Kahuna's First and Last name. We then send that information to the server. The server stores that data using ADO, and generates a unique ID number. This unique ID number is now associated with this individual surfer. We send another page back to the browser confirming that the information was successfully saved. However, we also take the liberty to write a cookie to the surfer's PC. In the cookie, we store the unique number. Now the next time the user logs into our server, we read the cookie from the user's PC, grab the unique number and send it to the server. Using ADO, we retrieve the information about that user. This way we can track each and every visitor to our site and store any information we care to about this person. This is how all of the large professional web sites perform this magic. Like custom configuration of a page, or customized news stories, or just about any individualized page. It's done with cookies.

Hysteria was generated a few years back when surfers found out that servers could actually write to their hard drives. The Wall Street Journal even had a front page article about this. People felt their machines were being violated. They also feared that servers could read the contents of their hard drive to find any illegal copies of software that might be there. However, this is not the case. And cookies proved so useful that the World Wide Web Consortium has endorsed a cookie standard.

© 1998 by Wrox Press. All rights reserved.

MSDN Magazine Blog

MSDN Magazine Right Rail

14 Top Features of Visual Basic 14: The Q&A
Leading off the feature in the January issue of MSDN Magazine is Lucian Wischik’s fantastic look at Visual Basic .NET 14. As Wischik writes, the newes... More...
Wednesday, Jan 7
Big Start to the New Year at MSDN Magazine
Folks, things are hopping over here at MSDN Magazine. We are kicking off the new year with a pair of issues: Our regularly scheduled January issue and... More...
Friday, Jan 2

More MSDN Magazine Blog entries >

Receive the MSDN Flash e-mail newsletter every other week, with news and information personalized to your interests and areas of focus.