 |  |
| |
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.
Cookies work in the following way: when a CGI program identifies a new user, it adds an extra header to its response containing an identifier for that user and other information the server may glean from the client's input. This header informs the cookie-enabled browser to add this information to the client's cookies file. After this, all requests to that URL from the browser will include the cookie information as an extra header in the request. The CGI program uses this information to return a document tailored to that specific client. The cookies are stored on the client user's hard drive, so the information remains even when the browser is closed and reopened.
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
Multiple Set-Cookie headers may be included in the server response. The name=value pair is the only required attribute for this header, and it should come first. The remaining attributes can be in any order and are defined as follows:
Wednesday, 01-Sep-96 00:00:00 GMT
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.
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:
http://www.ietf.org/internet-drafts/draft-ietf-http-state-man-mec-10.txt
|  | |
| 17.3. HTTP Headers |  | 17.5. Media Types and Subtypes |
Copyright © 2003 O'Reilly & Associates. All rights reserved.