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
CSS Properties
Database
Design
Flash
HTML
HTML 4.01 Tags
JavaScript
.NET
PHP
Reference
Security
Site Management
Video
XML/RSS
WD Forums
 Client-Side
  Development

    HTML
    XML
    CSS
    Graphics
    JavaScript
    ASP
    Multimedia
    Web Video
    Accessibility
    Dreamweaver
    General
    Accessibility
    Dreamweaver
    Expression Web

    General

 Server-Side
  Development

    PHP
    Perl
    .NET
    Forum, Blog, Wiki & CMS
    SQL
    Java
    Others

 Site Management
    Domain Names
    Search Engines
    Website Reviews

 Web Development
  Business Issues

    Business Matters

 Etc.
    The Coffee Lounge
    Computer Issues
    Feedback




Cookies: Fresh From Your Browser's Oven

by Glenn Fleishman

A furor has erupted over cookies, but it has nothing to do with urban legends of Neiman-Marcus recipes and the infamous Visa charges that come with them. It has everything to do with the fact that the world has discovered that Netscape Navigator and other browsers — my God! — can retain limited information about a user's browser across sessions, and can store it locally on the user's hard disk.

Cookies have been around since the introduction of Netscape Navigator 1.1 in March 1995, but it wasn't until recently that their capability was exploited, and users began to recognize the potential loss of privacy in having a place on their own computer where persistent information could be stored.

In truth, there's nothing particularly frightening about cookies, except in their potential for misuse. Cookies could be used to track all input from a user and drop it in a database, but they don't inherently contain private information; they can only be associated with information users provide about themselves. For instance, a server could store a cookie like USER=80234832, which conveys nothing to that particular server's database or tracking system.

Fundamentally, a cookie is a long-text token associated with a domain and a path that the browser and server pass back and forth. Technically, the cookie is passed via an HTTP header and stored by the server in the client variable HTTP_COOKIE and by the browser in a local file.

The parameters of cookies are not all well-defined, and some bugs in implementation in different browsers require more explicit details than should be required. For instance, Netscape 1.1 requires an explicit path to be sent, or the cookie will not be retained. Working drafts from the Internet Engineering Task Force (IETF) already are under way toward defining what some think the next generation of cookies should do.

Rolling the Batter

Cookies are stored locally by a user's browser in a variety of places, depending on platform and vendor. Usually, the cookie file is found in the Preferences folder, application subdirectory, or home directory for Macintosh, Windows, and Unix respectively.

The cookie file shouldn't be edited by hand, as browsers store cookies internally during a session; Netscape, for instance, doesn't write new cookies until the application is exited.

The two top browsers, Microsoft Internet Explorer and Netscape Navigator, both handle cookies with relative aplomb. A few other browsers also can do the cookie dance (see a short list at Andy's Cookie page or a more elaborate list at Digital Equipment Corp.'s site; see "Resources").

The server can assign a number of cookies to the browser, with the following limits as Netscape has documented, specified, and implemented them:

  • 300 total cookies.
  • 20 cookies per domain matching pattern.
  • 4,096 characters per cookie, including the variable name.

Cookies are truncated to 4K characters, and older cookies are aged out in a first-in, last-out order when totals are exceeded.

The server and browser do a little dance in this exchange of information (see "Cookie Fillings"). Two scenarios unfold:

  • Browser has one or more cookies. When the browser reaches a page for which cookies match the domain pattern, path, and security, its HTTP headers will include the cookies in the form:

Cookie: variable=value; variable= value; (until variables are done)

The server stores the information in the HTTP_COOKIE variable, accessible through $ENV{'HTTP_COOKIE'} in Perl or getenv("HTTP_COOKIE") in C++. The server doesn't have to echo cookies in its response.

  • Server wants to feed a cookie. If you have a script set up, or a module such as NSAPI/ISAPI) set up to automatically feed cookies, the server includes in its HTTP headers:
Set-Cookie: variable=value;
expires=date; path="/path";
domain="domain pattern"[; secure]

One of these headers is required per variable and value pair; they can all be placed in the same header, however. The limit is 20 cookies per domain, so you have to be careful to pack data in long strings, rather than duplicating existing arrays. Cookies are reset by sending a Set-Cookie header with the same variable name. For instance:

Set-Cookie: order=""; expires="01-Jan-90
GMT"; path="/"

would reset the "order" cookie immediately. The expires setting is probably not necessary, but is not a bad thing to include (in the IETF draft for next-generation cookies, the expiration would be set by specifying the persistence length of the cookie, rather than a day and time).

Who's Got the Cookie?

Browsers that support cookies send them across proxies and gateways as part of their HTTP headers. If thousands of folks at Sun Microsystems access your site, you'll see them as unique visitors — even if you don't know anything else about them.

Cookies offer the potential of tracking not just time-bounded unique visits, but in further defining individual visitors. In terms of that article, you have a hierarchy of visitors you can tell apart down to ones that you can't:

  • Registered user. They use a unique login and password, and can be identified by username and visit, with a cookie that might allow them to bypass a full login for privileged access.
  • Cookie, unregistered user. They are uniquely tagged, but nothing may be known about them (could be a shared university lab computer, or an individual dialing in). However, we can identify unique visits by unique visitors.
  • No cookie, unregistered user. You can only determine unique visits, but not by how many individuals (or individual browsers).

At present, the America Online (AOL) browser doesn't do cookies, and AOL can represent a significant percentage of overall site visits. Hopefully, the versions of the Explorer and Navigator browsers that AOL and CompuServe expect to supply to their users by the time you read this will retain their cookie functionality.

This change in browsers could open up the use of cookies to another 10 million users. Wow. (Read that with or without sarcasm, depending on whether you're building sites for business-to-business or direct consumer sales.)



HTML5 Development Center


Recent Articles