Cookies: The good and the bad
Kyle D. Lutes
If you want to do something useful with your Web applications, you need to save state information on visitors to a given page. This tip, excerpted from InformIT, tells one way to do that, using cookies. But there are downsides to cookies. The full tip on the site discusses other ways of saving state information.
Any real Web application will need to retain state information, so Web application developers use several coding techniques to retain state.
The ASP Response and Request objects both have a cookies collection property that makes writing and reading cookies easy. For example, if an application needs to remember a user's e-mail address, it can save the data to a cookie using code like this:
Response.Cookies("EmailAddr") = "firstname.lastname@example.org"
A cookie created like this will be destroyed when the user leaves the Web site. To make it persistent, an expiration date must be specified. For example, to remember the user's e-mail address for the next 30 days, the following code can be used:
Response.Cookies("EmailAddr") = "email@example.com" Response.Cookies("EmailAddr").Expires = Now + 30
Your application can then later attempt to retrieve the user's e-mail address from the cookie using the Request object. Here's an example:
EmailAddr = Request.Cookies("EmailAddr")
If the cookie doesn't exist on the client, the EmailAddr variable will contain an empty string.
Using cookies to retain state information is easy enough to code, but it's far from an ideal solution to the statelessness of HTTP. Each cookie should not exceed 4KB, each server or domain is allowed only 20 cookies, and servers should not expect a client to store more than 300 total cookies. State information is transmitted back and forth between the browser client and server, thus increasing data transmission times. But arguably the biggest disadvantage of cookies is that some users consider persistent cookies to be an invasion of their personal privacy.
Persistent cookie data is stored in files on the user's computer, so there is the potential that it could be used for purposes other than the original intent. For example, it could be used to track the sites that an individual visits. To see for yourself, the next time you borrow someone's PC, browse their cookies if you want to see what they do on the Web. Recent versions of MS IE store cookie information in a folder aptly named Cookies under the Windows folder, and Netscape Navigator stores all cookie information in a single cookies.txt file.
So, even if most modern Web browsers support the cookie protocol, they also recognize that cookies are controversial--and offer options that allow the user to disable them. This means that as a Web application developer, you cannot be certain that your application will be able to store state information in a cookie. Assuming that all users of your Web application will have cookies enabled is definitely a bad assumption, especially if you are developing an application for an e-commerce site that needs to work for as many users as possible.
To read this full tip, click over to InformIT. You have to register there, but registration is free.
Did you like this tip? Why not let us know? E-mail to share your opinion.
Author : Simon St. Lauren
Publisher : McGraw-Hill
Published : Mar 1998
Let Simon St. Laurent give you the full picture of how cookies fit into your Web tooklit and how they work with other tools: The truth about cookies' power to invade privacy, spread viruses, and breach security; Details to help you create cookies with maximum functionality, including client-side cookie scripting and server-side cookie applications; Step-by-step instructions on delivering content tailored to individual users; insights into the latest improvements to the cookie standard and new specifications from Microsoft and Netscape/Verisign, including the Open Profiling Standard; Sample cookie files and code; Advice on blending cookies and Java; Better ways to track site usage; simulated cookies for browsers that can't handle them; Alternative routes when users hostile to cookies have turned them off; the lowdown on higher=level user verification methods, such as digital signatures and encryption; site architecture considerations.
This was first published in August 2001