Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Cookies
One technique for retaining state is to use cookies. With cookies, the Web application on the server sends information to the browser, along with a request that the browser save the information. If the browser supports cookies, the data is written to a special file on the user's computer. Whenever the data is needed again, the Web application can ask the browser to send the same data back to the server. Netscape introduced cookies with the first version of its browser. Since then, the World Wide Web Consortium (W3C) has endorsed a cookie standard, and now most modern Web browser support cookies.
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") = "kdlutes@delmarit.com"
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 email address for the next 30 days, the following code can be used:
Response.Cookies("EmailAddr") = "kdlutes@delmarit.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.
A cookie created by an application on one server can't be retrieved by an application on another. That's the theory, anyway. But both Netscape Navigator and MS IE have at some time contained flaws that allowed cookies to be read by a site other than the site that created the cookie, and advertising firms such as DoubleClick use cookies to provide so-called personalized marketing services to Web sites. A program running on the user's PC also can easily access the cookie files. Whether cookies are good or evil is not something this author wishes to debate, but it's interesting to note that the use of persistent cookies by government Web sites was deemed a violation of federal privacy regulations, and they have been banned in almost all circumstances.
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.