Cookie 规范
INTRODUCTION
Cookies are a general mechanism which server side connections (such asCGI scripts) can use to both store and retrieve information on theclient side of the connection. The addition of a simple, persistent,client-side state significantly extends the capabilities of Web-basedclient/server applications.
OVERVIEW
A server, when returning an HTTP object to a client, may also send apiece of state information which the client will store. Included inthat state object is a description of the range of URLs for which thatstate is valid. Any future HTTP requests made by the client which fallin that range will include a transmittal of the current value of thestate object from the client back to the server. The state object iscalled a cookie, for no compelling reason.
This simple mechanism provides a powerful new tool which enables a hostof new types of applications to be written for web-based environments.Shopping applications can now store information about the currentlyselected items, for fee services can send back registration informationand free the client from retyping a user-id on next connection, sitescan store per-user preferences on the client, and have the clientsupply those preferences every time that site is connected to.
SPECIFICATION
A cookie is introduced to the client by including a Set-Cookie headeras part of an HTTP response, typically this will be generated by a CGIscript.
Syntax of the Set-Cookie HTTP Response Header
This is the format a CGI script would use to add to the HTTP headers anew piece of data which is to be stored by the client for laterretrieval.
Set-Cookie: NAME=VALUE; expires=DATE;
path=PATH; domain=DOMAIN_NAME; secure
NAME=VALUE
This string is a sequence of characters excluding semi-colon, comma andwhite space. If there is a need to place such data in the name orvalue, some encoding method such as URL style %XX encoding isrecommended, though no encoding is defined or required.
This is the only required attribute on the Set-Cookie header.
expires=DATE
The expires attribute specifies a date string that defines the validlife time of that cookie. Once the expiration date has been reached,the cookie will no longer be stored or given out.
The date string is formatted as:
Wdy, DD-Mon-YYYY HH:MM:SS GMT
This is based on RFC 822, RFC 850, RFC 1036, and RFC 1123, with thevariations that the only legal time zone is GMT and the separatorsbetween the elements of the date must be dashes.
expires is an optional attribute. If not specified, the cookie will expire when the user's session ends.
Note: There is a bug in Netscape Navigator version 1.1 and earlier.Only cookies whose path attribute is set explicitly to "/" will beproperly saved between sessions if they have an expires attribute.
domain=DOMAIN_NAME
When searching the cookie list for valid cookies, a comparison of thedomain attributes of the cookie is made with the Internet domain nameof the host from which the URL will be fetched. If there is a tailmatch, then the cookie will go through path matching to see if itshould be sent. "Tail matching" means that domain attribute is matchedagainst the tail of the fully qualified domain name of the host. Adomain attribute of "acme.com" would match host names "anvil.acme.com"as well as "shipping.crate.acme.com".
Only hosts within the specified domain can set a cookie for a domainand domains must have at least two (2) or three (3) periods in them toprevent domains of the form: ".com", ".edu", and "va.us". Any domainthat fails within one of the seven special top level domains listedbelow only require two periods. Any other domain requires at leastthree. The seven special top level domains are: "COM", "EDU", "NET","ORG", "GOV", "MIL", and "INT".
The default value of domain is the host name of the server which generated the cookie response.
path=PATH
The path attribute is used to specify the subset of URLs in a domainfor which the cookie is valid. If a cookie has already passed domainmatching, then the pathname component of the URL is compared with thepath attribute, and if there is a match, the cookie is considered validand is sent along with the URL request. The path "/foo" would match"/foobar" and "/foo/bar.html". The path "/" is the most general path.
If the path is not specified, it as assumed to be the same path as thedocument being described by the header which contains the cookie.
secure
If a cookie is marked secure, it will only be transmitted if thecommunications channel with the host is a secure one. Currently thismeans that secure cookies will only be sent to HTTPS (HTTP over SSL)servers.
If secure is not specified, a cookie is considered safe to be sent in the clear over unsecured channels.
Syntax of the Cookie HTTP Request Header
When requesting a URL from an HTTP server, the browser will match theURL against all cookies and if any of them match, a line containing thename/value pairs of all matching cookies will be included in the HTTPrequest. Here is the format of that line:
Cookie: NAME1=OPAQUE_STRING1; NAME2=OPAQUE_STRING2 ...
Additional Notes
Multiple Set-Cookie headers can be issued in a single server response.
Instances of the same path and name will overwrite each other, with thelatest instance taking precedence. Instances of the same path butdifferent names will add additional mappings.
Setting the path to a higher-level value does not override other morespecific path mappings. If there are multiple matches for a givencookie name, but with separate paths, all the matching cookies will besent. (See examples below.)
The expires header lets the client know when it is safe to purge themapping but the client is not required to do so. A client may alsodelete a cookie before it's expiration date arrives if the number ofcookies exceeds its internal limits.
When sending cookies to a server, all cookies with a more specific pathmapping should be sent before cookies with less specific path mappings.For example, a cookie "name1=foo" with a path mapping of "/" should besent after a cookie "name1=foo2" with a path mapping of "/bar" if theyare both to be sent.
There are limitations on the number of cookies that a client can storeat any one time. This is a specification of the minimum number ofcookies that a client should be prepared to receive and store.
300 total cookies
4 kilobytes per cookie, where the name and the OPAQUE_STRING combine to form the 4 kilobyte limit.
20 cookies per server or domain. (note that completely specified hostsand domains are treated as separate entities and have a 20 cookielimitation for each, not combined)
Servers should not expect clients to be able to exceed these limits.When the 300 cookie limit or the 20 cookie per server limit isexceeded, clients should delete the least recently used cookie. When acookie larger than 4 kilobytes is encountered the cookie should betrimmed to fit, but the name should remain intact as long as it is lessthan 4 kilobytes.
If a CGI script wishes to delete a cookie, it can do so by returning acookie with the same name, and an expires time which is in the past.The path and name must match exactly in order for the expiring cookieto replace the valid cookie. This requirement makes it difficult foranyone but the originator of a cookie to delete a cookie.
When caching HTTP, as a proxy server might do, the Set-cookie response header should never be cached.
If a proxy server receives a response which contains a Set-cookieheader, it should propagate the Set-cookie header to the client,regardless of whether the response was 304 (Not Modified) or 200 (OK).
Similarly, if a client request contains a Cookie: header, it should beforwarded through a proxy, even if the conditional If-modified-sincerequest is being made.
EXAMPLES
Here are some sample exchanges which are designed to illustrate the use of cookies.
First Example transaction sequence:
Client requests a document, and receives in the response:
Set-Cookie: CUSTOMER=WILE_E_COYOTE; path=/; expires=Wednesday, 09-Nov-99 23:12:40 GMT
When client requests a URL in path "/" on this server, it sends:
Cookie: CUSTOMER=WILE_E_COYOTE
Client requests a document, and receives in the response:
Set-Cookie: PART_NUMBER=ROCKET_LAUNCHER_0001; path=/
When client requests a URL in path "/" on this server, it sends:
Cookie: CUSTOMER=WILE_E_COYOTE; PART_NUMBER=ROCKET_LAUNCHER_0001
Client receives:
Set-Cookie: SHIPPING=FEDEX; path=/foo
When client requests a URL in path "/" on this server, it sends:
Cookie: CUSTOMER=WILE_E_COYOTE; PART_NUMBER=ROCKET_LAUNCHER_0001
When client requests a URL in path "/foo" on this server, it sends:
Cookie: CUSTOMER=WILE_E_COYOTE; PART_NUMBER=ROCKET_LAUNCHER_0001; SHIPPING=FEDEX
Second Example transaction sequence:
Assume all mappings from above have been cleared.
Client receives:
Set-Cookie: PART_NUMBER=ROCKET_LAUNCHER_0001; path=/
When client requests a URL in path "/" on this server, it sends:
Cookie: PART_NUMBER=ROCKET_LAUNCHER_0001
Client receives:
Set-Cookie: PART_NUMBER=RIDING_ROCKET_0023; path=/ammo
When client requests a URL in path "/ammo" on this server, it sends:
Cookie: PART_NUMBER=RIDING_ROCKET_0023; PART_NUMBER=ROCKET_LAUNCHER_0001
NOTE: There are two name/value pairs named "PART_NUMBER" due to theinheritance of the "/" mapping in addition to the "/ammo" mapping.
