

Book HomeWebmaster in a Nutshell, 3rd EditionSearch this book

17.4. Cookies

Persistent-state, client-side cookies were introduced by Netscape Navigator to enable a server to store client-specific information on the client's machine and use that information when a server or a particular page is accessed again by the client. The cookie mechanism allows servers to personalize pages for each client, or remember selections the client has made when browsing through various pages of a site—all without having to use a complicated (or more time-consuming) CGI/database system on the server's side.


17.4.1. The Set-Cookie Response Header

A cookie is created when a client visits a site or page for the first time. A CGI program looks for previous cookie information in the client request and, if it is not there, sends a response containing a Set-Cookie header. This header contains a name/value pair (the actual cookie) that comprises the special information you want the client to maintain. There are other optional fields you may include in the header.

The Set-Cookie header uses the following syntax:

Set-Cookie: name=value; expires=date;path=pathname; domain=domain-name; secure



This attribute sets the date when a cookie becomes invalid. The date is formatted in a nonstandard way, like this:


After this date, the cookie becomes invalid, and the browser no longer sends it. Only GMT (Greenwich Mean Time) is used. If no expires date is given, the cookie is used only for the current session.


This attribute specifies a domain name range for which the cookie is returned. The domain-name must contain at least two dots (.), e.g., .oreilly.com. This value covers both www.oreilly.com and software.oreilly.com, and any other server in the oreilly.com domain.

The secure attribute tells the client to return the cookie only over a secure connection (via SHTTP and SSL). Leaving out this attribute means that the cookie is always returned, regardless of the connection.

17.4.2. The Cookie Request Header

Each time a browser goes to a web page, it checks its cookies file for any cookies stored for that URL. If there are any, the browser includes a Cookie header in the request containing the cookie's name=value pairs.

Cookie: name1=value1; name2
=value2; . . .

Returned cookies may come from multiple entries in the cookies files, depending on path ranges and domain ranges. For instance, if two cookies from the same site are set with the following headers:

Set-Cookie: Gemstone=Diamond; path=/
Set-Cookie: Gemstone=Emerald; path=/caves

when the browser requests a page at the site in the /caves path, it returns:

Cookie: Gemstone=Emerald; Gemstone=Diamond

Both items share the same name, but since they are separate cookies, they both apply to the particular URL in /caves. When returning cookies, the browser returns the most specific path or domain first, followed by less specific matches.

When the Cookie header is encountered, many servers pass the value of that header to CGI programs using the HTTP_COOKIE environment variable. See Chapter 12 for more information on CGI environment variables.

The preliminary cookies specification places some restrictions on the number and size of cookies:

  • Clients should be able to support at least 300 total cookies. Servers should not expect a client to store more.

    The limit on the size of each cookie (name and value combined) should not exceed 4KB.

  • A maximum of 20 cookies per server or domain is allowed. This limit applies to each specified server or domain, so www.oreilly.com is allowed 20, and software.oreilly.com is allowed 20, if they are each specified by their full names.

An issue arises with proxy servers in regard to the headers. Both the Set-Cookie and Cookie headers should be propagated through the proxy, even if a page is cached or has not been modified (according to the If-Modified-Since condition). The Set-Cookie header should also never be cached by the proxy.

Most web servers and clients still support the original cookie specification proposed by Netscape. Recently, the IETF has issued an Internet draft proposal for an updated cookie specification. This document describes new Set-Cookie2 and Cookie2 headers to eventually replace the original headers. They add additional attributes for comments and path specifiers.

Clients and servers that implement the new headers should be backwards-compatible with the original specification. The draft proposal can be found at the following URL:


Library Navigation Links

Copyright © 2003 O'Reilly & Associates. All rights reserved.