They are most commonly used to track, store preferences or shopping cart information from and recognise users.
The majority of the information is based on the Netscape Cookie Specification.
Setting Cookies
For security reasons, web sites cannot create globally accessible cookies that any web site or web page can view. So cookies are set for a particular domain, path, time period and security level.
They are generally set using the Set-Cookie: http response header, when a file is sent, e.g.:
Set-Cookie: MYCOOKIE=VALUE; expires=Thu, 28-Jun-2001 12:13:02 GMT; path=/; domain=iconbar.com
This would mean that any subsequent connection to the iconbar.com would include the following header:
Cookie: MYCOOKIE=VALUE
The attributes in the Set-Cookie are as follows:
<COOKIE_NAME>=<COOKIE_VALUE>;
This specifies the cookie's name and value. These are the only required attributes, all else are optional.
expires=<DATE_TIME>;
If not set, the cookie will be deleted at the end of the user's session. (i.e. when they quit their web browser)
The date must be the form "Wdy, DD-Mon-YY HH:MM:SS GMT", e.g. Thu, 28-Jun-2001 12:13:02 GMT (This is based on RFC 822, 850, 1036 and 1123, with the exception that only the GMT timezone is permitted and the date separators must be dashes)
domain=<DOMAIN_NAME>;
If not set, this defaults to the host serving the file, otherwise it is only permitted if the host is within the specified domain. (e.g. fonts.iconbar.com could set a cookie which is valid for iconbar.com and vice versa, but iconbar.com could not set a cookie which is valid for
acornarcade.com)
The specified domain must contain at least two periods if it ends in .com, .edu, .net, .org, .gov, .mil or .int, otherwise it must contain at least three.
path=<PATH>;
If not set, this defaults to the path of the document being served. This limits the cookie to being supplied within the path specified. e.g. If set to '/' it would be sent for all otherwise valid requests to the server, but if set to /foo, it would match /foobar or /foo/bar.html -
i.e. it is simple left hand edge string comparison.
secure
If this is specified then the cookie is only sent over secure (currently only https) connections.
Notes:
- Multiple Set-Cookie headers can be included in one response.
- Cookies must never exceed more than 4Kb in length
- Max 20 cookies per server/domain
- Cookies are deleted by setting an expiry time which is in the past
and specifying the same path and name.
Code Examples
In PHP
PHP makes the setting and reading of cookies look childishly simple - so I haven't bothered to actually include a sample script at all.
PHP handles the cookies in the same transparent way as it handles the GET and POST variables and can set them as global variables, or just in the $HTTP_COOKIE_VARS array. Despite this, some understanding of how cookies work is required (particularly if you intend to delete unneeded cookies or don't know why a cookie hasn't appeared in the $HTTP_COOKIE_VARS array even though you just set it)
SetCookie($name [,$value [,$expires [,$path [,$domain [,$secure]]]]]); will only work before headers have been sent (check using if (!headers_sent()) setcookie(...);)
The major differences to note are that
expiresis a unix timestamp (i.e. seconds from 1/1/1970)secureis an boolean value (ie. not the string 'secure')
Set-Cookie: response header, with the exception that encoding is not required (PHP will automatically urlencode and decode the names and values).In Perl
Unless using CGI.pm or cgi-lib.pl, you'll have to do all the handling of cookies using environment variables and headers.
Download perl (en|de)coder
Setting cookies will need to be done before anything is sent to the client (other than other headers :), suitably encoding the data and using the Set-Cookie: header.
In BASIC
Cookies will need to be dealt with as in Perl.