Cookies Part One

In the first part of cookies, I'm going to discuss the 'in general' aspects. In the second part, I'll go over specifics & examples of using cookies.

Cookies - What They Are

HTTP is, by design, a stateless protocol. Each HTTP transaction occurs independent of any previous or future transaction. Each transaction (session) consists of these steps:

1) user connects to a HTTP server, making a request for a web page (or other data)
2) server acknowledges request, responds with web page (or other data)
3) transaction is terminated (disconnects)

There is no way for the server to "relate" transactions to each other. No way for the server to know there was a previous transaction with a particular client nor what happened if there was. Hence, the concept of stateless.

Cookies got their start as a mechanism to allow HTTP servers to 'know something' about previous transactions with a client. That is, provide session state information to the server. Cookies are implemented as two HTTP headers sent from the server to a client. One header to write a cookie and the other to read a cookie. What a client does with the cookie headers (if anything) is left to the client. The client determines if a cookie is saved or if a saved cookie is returned to the requesting server.

Cookies are part of the Internet Official Protocol Standards. These protocol standards are determined by the Internet Engineering Task Force (IETF). As protocols are developed or amended, the proposed protocol standard is published as a Request For Comment (RFC). After any amendments based on feedback from the RFC, the RFC then becomes the protocol integrated into Internet Official Protocol Standards. The current protocol for cookies is described in RFC 2109. A complete list of Internet protocol standards can be found at http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc2700.html.

In practice, HTTP clients (Browsers) only give users three choices with regard to cookies: Allow all cookies, refuse all cookies, be nagged and asked about each and every cookie. There are some changes on the horizon (both to the protocol & Browsers) that will give users the ability to 'fine tune' cookies. Some of these changes include a privacy policy associated with a cookie with the ability to accept or reject a cookie based on that policy and the ability to selectively accept or reject cookies based on the server's domain.

Anatomy of a Cookie

The parts of a cookie are Name, Domain, Path, Max-Age (Expires)* , Version*, Secure, and Value (the cookie data itself). Cookie Names are a sequence of characters excluding semi-colon, comma, "$" and white space. They are not case sensitive.

Cookies always "belong" to a domain. Servers can write and read cookies only for their own domain or immediate sub-domain (The "AD boys" have found some interesting work around for this - but that's another tale!). I'll go into this more with next issue's examples.

Path allows different directories on a server to have associated cookies (e.g., MySite.com/download/ & MySite.com/purchase/ could each have specific cookies).

Expires/Max-Age determine the cookies lifetime, with a value of zero meaning "throw me away now".

If Secure is specified, it means the cookie can only be sent through a secure protocol.
Version is a new addition to the protocol. If absent, it is assume the cookie format is the older netscape style. If present, it must be "1".

Browsers place restrictions on the number of cookies that can be held at any one time. The restrictions are:
20 cookies maximum per domain.
4096 bytes per cookie description.
300 cookies overall maximum.

RFC 2109 says at least these maximums. Netscape's specification and browsers say at most these maximums. Internet Explorer does not have 20 cookie per domain limit. If the maximums are exceeded, a new cookie will overwrite an older cookie of the domain. I'm not sure what happens if the 300 cookie limit is exceeded & there is no older cookie belonging to that domain to overwrite.

* - Recent changes to the cookie protocol include the addition of Version & Comment attributes. Previously, Expires, which contained an actual GMT Date-Time, was used to determine cookie life. This is being replaced with Max-Age which contains # of seconds for a cookie to live. See: RFC 2109 HTTP://www.cis.ohio-state.edu/cgi-bin/rfc/rfc2109.html.

Sending Cookies

There are several ways to initiate sending and receiving a cookie. They include:
- set/read from script - javascript, vbscript, DHTML
- set/read from server - ASP, CGI, ISAPI
Regardless of the method, it will always require client cookies to be enabled to work.

I'll discuss specifics on sending and receiving cookies using javascript next month.

Problems using Cookies

The most obvious problem relying on cookies is a user completely disabling them. If your web page relies on them, it won't work correctly. The best you can do in this circumstance is detect that cookies are disabled and then redirect to another page that doesn't rely on a cookie.

Cookies are browser specific. A cookie given to Netscape is no cookie for Internet Explorer. It's possible to partially work around this but can get pretty involved. One technique is to maintain the session data on your server with the cookie data only containing a User ID to look the data up. If the user changes Browsers, you need only provide a mechanism to get the ID. This is also a problem with different versions of the same Browser. It can also pose a problem depending on how a user has logged on to a Windows 9X system. If User Profiles are enabled & the user logs into a profile, the cookie data will come from Profiles\User_Name\Cookies. If the user clicked Cancel at log on, cookies will come from Windows\Cookies.

Multiple Browser windows can gum up the works. Because cookies belong to a Domain, if a user has the same site opened on 2 separate windows, one window can over write the other windows cookie. Again, it's possible to work around this. For example, each session can have an independent ID. The big question being just how much time, effort & server resources to spend.

Modified cookies. There is nothing to stop a user from editing the content of a cookie. If you are relying of the data you put there, you need to provide a verification mechanism (e.g., checksum).

And as the above problems suggest, using cookies for anything non-trivial means additional work for you as the web author. You need to give some thought to how much you want to invest in it and how to handle when cookies don't work.

Cookies and Privacy

Computer privacy has become a big issue - IMHO for some good reasons. By design, the cookie mechanism is anonymous - it does not include any personal identifiable information about a user. The information a server puts into a cookie is another matter. If a user provides you with their name, birth date or other personal information there is nothing to stop you from writing that information in the content of a cookie. In short, Bad Idea. Cookies are not secure with the 'possible' exception of using server side encryption for the content. In any other case, it must be assumed the cookie is readable by whoever chooses to look at it. The point being the content of cookies should be given careful consideration.

Client side encryption isn't encryption. This may discourage a casual user from viewing a cookie's content, but it doesn't take much effort to get around it since you HAVE to give them the encryption routine!

Don't assume a cookie has been deleted. Even if Max-Age is set to zero, this only tell a Browser it's ok to throw the cookie away. It has nothing to do with whether the Browser in fact does so. It is possible to set the Cookie data to a blank string effectively erasing the content, but there is no way to guarantee that it happened - the user can close the brower window before it happens.

If your page really needs access to personal data about a user, the best practice is to store the information server side in a secure database.

I suspect user concern for privacy is the main reason to disable browser cookies. I'm hopeful that as the new cookie protocol & Browsers become available, that users will take advantage of the ability to be selective rather than just disable them.

Some of the big AD sites and sites that "phone home" (e.g., some download managers) have also influenced users in disabling cookies. These guys have spent huge amounts of resources to be able to track a user's web usage and (reportedly) attempt to associate identities with the usage profiles. They have generated enough negative media to give cookies a bad name making legitimate use of cookies more difficult.

Next Issue

I'll go over some "how to use cookies" and some javascripts to read, write, & access data in cookies.

A big Thank You to Dennis Reinhardt for pointing out some of the problems of cookie usage.

Want to see the cookie data for a web page? Browse to the page, then type (paste) this into the URL box: JavaScript:alert(document.cookie.split(';').join('\n'))

Cookie Web Resources

http://msdn.microsoft.com/library/partbook/instantj/cookietheory.htm
http://msdn.microsoft.com/library/partbook/instantj/usingcookies.htm
http://www.cis.ohio-state.edu/cgi-bin/rfc/rfc2109.html
http://www.netscape.com/newsref/std/cookie_spec.html
http://www.cookiecentral.com/

Making Cookies - Part One