June 30, 2005
By Karen Kenworthy
IN THIS ISSUE
What a life. You sit in a small box all day, alone, in the dark. Every few seconds, through a small hole, come tiny pieces of paper. On each is written the word "GET", followed by the name of a document or picture.
As quickly as you can, you retrieve the requested item from the shelves behind you, push it out the same hole from whence came the request, and brace for another order. You don't have to wait long. Demands for items in your files come several times a minute, every minute, of every hour, of every day.
Does that sound like an awful science fiction movie? Or your last job? Well it's actually a scene from the recent past, one that was played out in thousands of places around the world. It's a slice from the life of any early web server.
Browser When someone like you or I want to view a web page, we run a program called a "web browser". Once we tell it which page we'd like to see, the program sends a request to the server that houses the page. The request literally consists of the word "GET", followed by the name of the file where the page is stored.
Server In the early days, a web server's job was easy -- if stupefyingly monotonous. Requested items were retrieved, then sent back to the computer making the request. The server didn't even care which computer asked for the data. The Internet took care of that detail, automatically routing the reply along the same electronic path the request had followed.
Browser Once our browser receives a page from a web server, it "parses" the page's content, looking for references to pictures and other files. If the original page contains any of these, additional "GET" commands are issued for each one. Finally, when all the necessary files have been assembled, our web browser displays the combined result.
Server Perhaps to fight boredom, and definitely to keep up with ever-escalating traffic, web servers gradually became more efficient. Most learned to keep a small collection of their most popular files close at hand, in their computer's memory. They called this region of memory their "cache". Only the more obscure requests drove the server to access its slower disk files.
Browser Web browsers became more efficient too. They learned to store bits and pieces of the web sites we visit on our hard disks. Later, if we ask the browser to visit the same site again, they check this "cache." If they already have what we need, the roundtrip to the web server is avoided.
And that's were the state of the art stood -- for a while. Web browsers requested files on our behalf, but only if they didn't already have a recent copy. And servers obediently and swiftly responded to each request they received.
Ah, the good old days ...
Think of those old web servers as helpful librarians, with amnesia. They could remember a request just long enough to fulfill it. But after the requested file was on its way, the web server forgot all about the transaction.
That worked well back then. But today we expect much more of these data dispensers.
Consider a simple web store. Each time we click on a picture of some tempting product, our web browser asks the store's server for a page containing additional product details. As we continue strolling through the virtual showroom, one click at a time, the store's server continues to send us the text and pictures we need. Any old web server could do this job.
But what if we decide to make a purchase? Now things get interesting. It starts when we click that "Add to Cart" button next to the picture of the irresistible doodad we just now realize we can't live without. What happens next?
Immediately, our web browser sends a special message to the store's server, telling it of our decision. Now the server must do something we haven't seen before. It must make a mental note of our selection -- remembering it until we finish our shopping trip.
This is a remarkable development. Suddenly, a web server's amnesia must be cured. From now on, the store's server must recognize us, and treat our requests for data in a special way.
Now, if we ask to see our shopping cart, the page sent to our browser must be unique. It must contain the items we've selected, not those of any other shopper. Once we begin the "Checkout" process, the server must remember more and more information - not only the items in our cart, but our shipping address, name, billing address, credit card information, and any other details we provide.
Not until we click that last "Submit Order" button can the server transmit our order to the shipping department, finally forget all about us, and relax. Until the next customer arrives ...
Web servers can store information in two places, their computer's memory, or on their disks. But how does the server know us, distinguish our web page requests from all others? How does it match our requests with its growing collection of information about us?
The answer is something programmers call a "cookie".
No, these aren't tasty disks of dough. Sadly, to a programmer, a cookie is just a small bit of data.
Computer cookies have lots of uses, and come in several flavors. But for now, let's stick to those cookies that help web servers recognize us, and make possible many of the features of advanced web sites.
Server These "web cookies" begin their lives within web servers. That's where they are "baked", where their ingredients, err, contents are chosen.
Cookies leave the servers neatly tucked inside web pages. From there, they travel across the Internet until they finally are received by a web browser running on our computer.
Browser What happens next? Our web browsers don't "process" cookies. They don't know, or even care, what data a cookie might contain. Instead, browsers simply store each cookie they receive, either in our computer's memory, or on our hard disk.
Server You might think one wild trip across the Internet would be enough for these digital pastries. But the next time we request information from a web site, any cookies we've previously received from that site are returned to the land of their birth, sent back to the server that created them.
And that's the life of a web cookie. They are created by a web server, and come to us ridding piggyback on a web page we've requested. Afterwards, each of our requests sent to that server contain copies of those cookies it sent.
You've probably guessed how cookies solve the "identity" problem we talked about a moment ago. A web cookie could, and often does, contain a unique number assigned to us by the web server. Later, when more of our requests arrive, the server recognizes us by the content of the cookies we return.
Once you make your selections, by clicking the "Preferences" link on any of my web pages, your choices are sent to your browser in a cookie. Ever after, your browser reminds my site of your choices by sending a copy of that cookie with every page request.
The data stored in a cookie is ignored by our web browser. But that doesn't mean we have to be in the dark. After all, copies of our cookies are stored on our computer's hard disk. All we need is the right program, one that opens those cookie jars and displays their contents.
That's why, a few years ago, I wrote a Power Tool called Karen's Cookie Viewer. It could locate and display most cookies stored by Microsoft's Internet Explorer, and Netscape's Navigator, web browser. After a while, it also learned how to delete any of those cookies that didn't suit our tastes.
Recently, another web browser has become popular. It's called FireFox, written by a non-profit group of software developers called the Mozilla project:
FireFox is a terrific web browser, chock full of great features. But unfortunately, as the popularity of FireFox grew, so did the number of folks who couldn't see their cookies using my Cookie Viewer.
But no longer. I've just updated my Cookie Viewer, adding the ability to view and delete cookies kept by FireFox browsers. Other enhancements include a help file, and the ability to browse your computer's hard disk looking for cookie collections the program's automatic search may have overlooked.
I've also made several small improvements to the way the program displays a cookie's contents, and made it easier to delete several cookies at a time. The program even decodes and displays one new bit of data, called "Scope", found in Netscape and FireFox cookies.
There's a lot more to say about cookies -- what they contain and how they are used. But that will have to wait until we get together again. In the meantime, you can start studying the cookies on your drives using the new Cookie Viewer. Just download your copy from its home page at:
As always, the program is free for personal/home use. If you're a programmer, you can download its complete Visual Basic source code too!
You can also get the latest version of every Power Tool, including the new Cookie Viewer, on a shiny CD. These include three bonus Power Tools, not available anywhere else. The source code of every Power Tool, every issue of my newsletter, and some articles I wrote for Windows Magazine, are also on the CD. And owning the CD grants you a special license to use all my Power Tools at work.
Best of all, buying a CD is the easiest way to support the KarenWare.com web site, Karen's Power Tools, and this newsletter. To find out more, visit:
Until next time, munch all the web cookies you can. They're 100% calorie free! And if you see me 'net, be sure to wave and say "Hi!"
Power Tools Newsletter
- Directory Printer v5.4.4 Adds Unicode Characters Support
- Replicator v3.7.6 Eradicates Bug that caused Error 3
31758 Verified Subscribers
Subscribe to receive new issues of the newsletter about Karen and her free Power Tools.Click here to Subscribe