Web Talk for Wireheads: Cookies
Part 1
Some Goodbye Cookies from Glen
In this space two issues ago, you saw the whole scope of cookies--their functionality, implementation, and some good examples. This column updates that topic, provides another, more dynamic example, and gives a plug for using cookies to understand more about visits and visitors. There's also an unrelated tidbit about a new release of sendmail; and, I bid farewell with this column--but read it first!
The use of cookies has become a little more acceptable to visitors due to an increased awareness of them and some new options that now ship with some browsers. But given the limitations of the medium, cookies are still the best, most reliable way to maintain state.
Scare Tactics or Education?
Since I wrote the column a few months ago, cookie awareness has increased, with vendors offering users the option of notifying them for certain "cookie behavior." Both Netscape Navigator and Microsoft Internet Explorer allow users this control with version 3.0.
Navigator introduced an alert setting under Network Preferences in the Protocols, which allows users to specify whether or not they should be notified when the server transmits a cookie to their browser (in the same dialog, they plugged a hole that an astute JavaScripter in Switzerland identified, which let JavaScript submit forms — even by e-mail — without the user's knowledge).
Checking the alert setting causes the browser to bring up a detailed dialog box that reads: The server [host and domain name] wishes to set a cookie that will be sent only back to itself. The name and value of the cookie are [name = value]. Do you wish to allow the cookie to be sent? [No] [YES]
Clicking no suppresses cookie storage; clicking yes, which is the highlighted choice, continues as normal.
Internet Explorer hides the setting a little deeper in the View menu /Options item /Advanced tab. Checking "Warn before sending cookie" activates the feature. Explorer's warning is worded better:
You have received a "cookie"
(Internet information stored on
your computer) from [domain or
domain range]
The contents are:
[contents]
It expires on [full datestamp]
Do you want to accept it? If you
click No, the page you are trying
to view may not display correctly.
[yes][no]
The HTTP header Set-Cookie can be set to allow any machine in a given domain to access cookies with the "domain=" flag. Setting "domain=.webdeveloper.com", for instance, causes the browser to send the cookie to any machine resolvable as something.webdeveloper.com. If you've made this choice, the Netscape message is:
The server [host and domain name]
wishes to set a cookie that will be
sent to any server in the domain
[domain name set with flag].
Netscape is clever to have made this choice, which does not allow disabling cookie transmission, as users can disable JavaScript and Java. Users that are paranoid, concerned, or merely interested in what values are being sent back and forth can use this option to prevent information from being transmitted that they don't approve of. Most users will leave the option checked for a short time, realize how harmless cookies are, and uncheck it. Others might upgrade to one of the programs or services that filter out cookies or even provide anonymous access.
This new option highlights an attitude of concern that's slowly being overcome. By giving them a choice, companies or groups can help users continue to overcome their reluctance to accept cookies. Since users now have several options to control or eliminate cookie transmission, the concerns behind it should fade, since it's not a black box procedure any more. I've left the option checked on most of the machines I work on, just to get a feeling for how others sites use and update cookies.
Syntax Correction and Reminder for Set-Cookie
In "Cookies: Fresh From Your Browser's Oven" in the July/August 1996 Web Developer®, a syntax problem was introduced in the editing stage in the Set-Cookie description. The format given included quotation marks around certain items, which are not only unnecessary, but cause an error. The correct syntax is:
Set-Cookie: variable=value; expires=date;
path=/path; domain=.domain.tld; secure
The semicolon delimits items, so quotation marks weren't needed. Everything but variable is optional. Expires will default to session (the next time the application is exited). Path defaults to "/", except with Netscape 1.1, in which the path variable must be set in every case, Domain default to just the host machine, and secure defaults to non-SSL transactions.
[ Web Talk for Wireheads: Cookies:
Part 2 > ] |
|
