|This is retired content. This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This content may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.|
The Set-Cookie response header uses the following syntax:
Set-Cookie: <name>=<value>[; <name>=<value>]... [; expires=<date>][; domain=<domain_name>] [; path=<some_path>][; secure]
One or more string sequences, separated by semicolons, that follow the pattern <name>=<value> must be included in the Set-Cookie response header. The server can use these string sequences to store data on the client's system.
The expiration date is set by using the format expires=<date>, where <date> is the expiration date in Greenwich Mean Time (GMT). If the expiration date is not set, the cookie expires after the Internet session ends. Otherwise, the cookie persists in the cache until the expiration date.
The following table shows the expiration date format.
|DD-MMM-YYYY HH:MM:SS GMT||Complete format.|
|DD||DD is the day in the month — such as 01 for the first day of the month.|
|MMM||MMM is the three-letter abbreviation for the month: (Jan, Feb, Mar, Apr, May, Jun, Jul, Aug, Sep, Oct, Nov, Dec).|
|YYYY||YYYY is the year.|
|HH:MM:SS GMT||HH is the hour value in military time — 22 would be 10:00 P.M., for example — MM is the minute value, and SS is the second value.|
Specifying the domain name, using the pattern domain=<domain_name>, is optional for persistent cookies and is used to indicate the end of the domain for which the cookie is valid. Session cookies that specify a domain are rejected. If the specified domain name ending matches the request, the cookie tries to match the path to determine if the cookie should be sent. For example, if the domain name ending is .microsoft.com, requests to home.microsoft.com and support.microsoft.com would be checked to see if the specified pattern matches the request. The domain name must have at least two or three periods in it to prevent cookies from being set for widely used domain name endings, such as .com and .edu. Acceptable domain names would be similar to .microsoft.com, .someschool.edu, and .someserver.co.jp. Only hosts within the specified domain can set a cookie for a domain.
Setting the path, using the pattern path=<some_path>, is optional and can be used to specify a subset of the URLs for which the cookie is valid. If a path is specified, the cookie is considered valid for any requests that match that path. For example, if the specified path is /example, requests with the paths /examplecode and /example/code.htm would match. If no path is specified, the path is assumed to be the path of the resource associated with the Set-Cookie header.
The cookie can also be marked as secure, which specifies that the cookie can be sent only to HTTPS servers.
Last updated on Friday, April 02, 2004