Web Talk for Wireheads: Cookies
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!
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.
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].
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 > ]