WebDeveloper.com �: Where Web Developers and Designers Learn How to Build Web Sites, Program in Java and JavaScript, and More!   
Web Developer Resource Directory WebDev Jobs
Animated GIFs
CSS Properties
HTML 4.01 Tags
Site Management
WD Forums

    Web Video
    Expression Web



    Forum, Blog, Wiki & CMS

 Site Management
    Domain Names
    Search Engines
    Website Reviews

 Web Development
  Business Issues

    Business Matters

    The Coffee Lounge
    Computer Issues

Web Talk for Wireheads: Cookies
Part 1

by Glenn Fleishman

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 > ]

HTML5 Development Center

Recent Articles