 |
Appendix F Persistent Client State: HTTP Cookies |
 |
F.4 Specification
A cookie is introduced to the client by including a Set-Cookie header as part of an HTTP response; typically this will be generated by a CGI script.
Syntax of the Set-Cookie HTTP Response Header
This is the format a CGI script would use to add to the HTTP headers a new piece of data which is to be stored by the client for later retrieval.
Set-Cookie: name=value; expires=date; path=path; domain=domain_name; secure
- name=value
-
This string is a sequence of characters excluding semicolons, commas, and white space. If there is a need to place such data in the name or value, some encoding method such as URL style %XX encoding is recommended, 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 valid lifetime 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 the variations that the only legal time zone is GMT and the separators between 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 be properly saved between sessions if they have an expires attribute.
When searching the cookie list for valid cookies, a comparison of the domain attributes of the cookie is made with the Internet domain name of the host from which the URL will be fetched. If there is a tail match, then the cookie will go through path matching to see if it should be sent. "Tail matching" means that domain attribute is matched against the tail of the fully qualified domain name of the host. A domain 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 domain and domains must have at least two (2) or three (3) periods in them to prevent domains of the form: .com, .edu, and va.us. Any domain that falls within one of the seven special top level domains listed below only require two periods. Any other domain requires at least three. 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.
The path attribute is used to specify the subset of URLs in a domain for which the cookie is valid. If a cookie has already passed domain matching, then the pathname component of the URL is compared with the path attribute, and if there is a match, the cookie is considered valid and 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 the document being described by the header which contains the cookie.
If a cookie is marked secure, it will only be transmitted if the communications channel with the host is a secure one. Currently this means 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 the URL against all cookies and if any of them match, a line containing the name/value pairs of all matching cookies will be included in the HTTP request. 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 the latest instance taking precedence. Instances of the
same path but different names will add additional mappings.
- Setting the path to a higher-level value does not override other
more specific path mappings. If there are multiple matches for a
given cookie name, but with separate paths, all the matching
cookies will be sent. (See examples below.)
- The expires header lets the client know when
it is safe to purge the mapping but the client is not required to
do so. A client may also delete a cookie before its expiration
date arrives if the number of cookies exceeds its internal
limits.
- When sending cookies to a server, all cookies with a more specific
path mapping should be sent before cookies with less specific path
mappings. For example, a cookie "name1=foo" with a path mapping
of / should be sent after a cookie
"name1=foo2" with a path mapping of /bar if
they are both to be sent.
- There are limitations on the number of cookies that a client can
store at any one time. This is a specification of the minimum
number of cookies 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 hosts and domains are treated as separate entities
and have a 20-cookie limitation 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 is exceeded, clients should delete the least recently used cookie. When a cookie larger than 4 kilobytes is encountered the cookie should be trimmed to fit, but the name should remain intact as long as it is less than 4 kilobytes.
- 300 total cookies;
- If a CGI script wishes to delete a cookie, it can do so by
returning a cookie 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 cookie to
replace the valid cookie. This requirement makes it difficult
for anyone 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-cookie header, 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 be forwarded through a proxy, even if the conditional If-modified-since request is being made.
|
 |
|
| Overview |  |
Examples |
