 |
Chapter 12 |  |
|
Chapter 12 | |
Contents:
The Set-Cookie Response Header
The Cookie Request Header
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 that 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 will look for previous cookie information in the client request, and if it is not there, will send a response containing a Set-Cookie header. This header contains a name/value pair (the actual cookie) which 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:
Both name and value can be any strings that do not contain either a semi-colon, space, or tab. Encoding such as URL encoding may be used if these entities are required in the name or value, as long as your script is prepared to handle it.
This attribute sets the date when a cookie becomes invalid. The date is formatted in a nonstandard way like this:
Wednesday, 01-Sep-96 00:00:00 GMT
After this date, the cookie will become invalid, and the browser will no longer send it. Only GMT (Greenwich Mean Time) is used. If no expires date is given, the cookie is used only for the current session.
The path attribute supplies a URL range for which the cookie is valid. If path is set to /pub, for example, the cookie will be sent for URLs in /pub as well as lower levels such as/pub/docs and /pub/images. A pathname of " / " indicates that the cookie will be used for all URLs at the site from which the cookie originated. No path attribute means that the cookie is valid only for the originating URL.
This attribute specifies a domain name range for which the cookie will be returned. The domain-name must contain at least two dots (.), e.g., .ora.com. This value would cover both www.ora.com and software.ora.com, and any other server in the ora.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 will always be returned regardless of the connection.
