[ Team LiB ] Previous Section Next Section


Netscape originated the "magic cookie" back in the days of Netscape 1. The origin of the name is the subject of some debate, although it seems reasonable to assume that the fortune cookie might have played a role in the thinking behind it. Since then, the standard has been embraced by other browser producers.

A cookie is a small amount of data stored by the user's browser in compliance with a request from a server or script. A host can request that up to 20 cookies be stored by a user's browser. Each cookie consists of a name, a value, and an expiry date, as well as host and path information. An individual cookie is limited to 4KB.

After a cookie is set, only the originating host can read the data, ensuring that the user's privacy is respected. Furthermore, the user can configure his browser to notify him of all cookies set or even to refuse all cookie requests. For this reason, cookies should be used in moderation and should not be relied on as an essential element of an environment design without first warning the user.

Having said that, cookies can be an excellent way of saving small amounts of information about a user from page to page or even from visit to visit.

The Anatomy of a Cookie

Cookies are usually set in an HTTP header (although JavaScript can also set a cookie directly on a browser). A PHP script that sets a cookie might send headers that look something like this:

HTTP/1.1 200 OK
Date: Mon, 25 Aug 2003 13:40:22 GMT
Server: Apache/2.0.47 (Unix) PHP/5.0.0b1
X-Powered-By: PHP/5.0.0b1
Set-Cookie: vegetable=artichoke; expires=Mon, 25-Aug-2003 14:40:27 GMT; path=/;
Connection: close
Content-Type: text/html; charset=ISO-8859-1

As you can see, the Set-Cookie header contains a name value pair, a GMT date, a path, and a domain. The name and value are URL encoded. The expires field is an instruction to the browser to forget the cookie after the given time and date. The path field defines the position on a Web site below which the cookie should be sent back to the server, whereas the domain field determines the Internet domains to which the cookie should be sent. The domain cannot be different from the domain from which the cookie was sent, but it can nonetheless specify a degree of flexibility. In the preceding example, the browser sends the cookie to the server corrosive.co.uk. You can read more about HTTP headers in Hour 14, "Beyond the Box."

If the browser is configured to store cookies, it keeps this information until the expiry date. If the user points the browser at any page that matches the path and domain of the cookie, it resends the cookie to the server. The browser's headers might look something like this:

GET /phpbook/source/listing19.1.php HTTP/1.1
Host: matt.corrosive.co.uk:9090
User-Agent: Mozilla/5.0 (X11; U; Linux ppc; en-US; rv:1.2.1) Gecko/20030228
Accept: text/xml,application/xml,application/xhtml+xml,text/html ...
Accept-Language: en-us, en;q=0.50
Accept-Encoding: gzip, deflate, compress;q=0.9
Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66
Keep-Alive: 300
Connection: keep-alive
Cookie: vegetable=artichoke
Cache-Control: max-age=0

A PHP script then has access to the cookie in the superglobal array variable $_COOKIE["vegetable"]:

print $_COOKIE['vegetable']."<br/>"; // prints "artichoke"

    [ Team LiB ] Previous Section Next Section