Cookie Fundamentals
Whether you are a programmer or just a web user looking for answers, a big part of understanding cookies is to go into the gory details.
Understanding how cookies really work requires an understanding of how HTTP works. Cookies transport from Server to Client and back as an HTTP header. The specifications for this header are explicitly laid out in RFC 2109.
When a cookie is sent from the server to the browser, an additional line is added to the HTTP headers (example):
This header entry would result in a cookie named foo. The value of foo is bar. In addition, this cookie has a path of /, meaning that it is valid for the entire site, and it has an expiration date of Dec 9, 2002 at 1:46pm Greenwich Mean Time (or Universal Time). Provided the browser can understand this header, the cookie will be set.
When a cookie is sent from the browser to the server, the cookie header is changed slightly:
Here, the server is made aware of a cookie called foo, whose value is bar.
As we have just seen, a cookie contains more than simply a name and a value. In fact, a cookie has 6 parameters that can be passed to it:
Two of these are mandatory (its name and its value). The other four can be set manually or automatically. Each parameter is separated by a semicolon when set explicitly. Here is a detailed description of each.
The name of a cookie and its value are set simply by pairing them together:
foo=bar
The value of a cookie can also be null, for the purpose of clearing the cookie value:
foo=
The expires parameter lets you determine the lifetime of the cookie.
expires=Mon, 01-Jan-2001 00:00:00 GMT
If Expires is not set explicitly, then it defaults to end-of-session. The length of a session can vary depending on browsers and servers, but generally a session is the length of time that the browser is open for (even if the user is no longer at that site).
The path parameter is potentially the most useful of the 4 optional cookie settings. It sets the URL path the cookie is valid within. Pages outside of that path cannot read or use the cookie.
path=/promo
If Path is not set explicitly, then it defaults to the URL path of the document creating the cookie.
Netscape has identified a bug for VERY old versions of Navigator where the path must be specified if an expiration is specified. Furthermore, this path must be set to "/".
The domain parameter takes the flexibility of the path parameter one step further. If a site uses multiple servers within a domain the it is important to make the cookie accessible to pages on any of these servers.
domain=www.myserver.com
Cookies can be assigned to individual machines, or to an entire Internet domain. The only restrictions on this value is that it must contain at least two dots (.myserver.com, not myserver.com) for the normal top-level domains, or three dots for the "extended" domains (.myserver.ny.us, not myserver.ny.us)
IMPORTANT: The server issuing the cookie must be a member of the domain that it tries to set in the cookie. That is, a server called www.myserver.com cannot set a cookie for the domain www.yourserver.com. The security implications should be obvious.
If Domain is not set explicitly, then it defaults to the full domain of the document creating the cookie.
The secure parameter is a flag indicating that a cookie should only be used under a secure server condition, such as SSL. Since most sites do not require secure connections, this defaults to FALSE.
See also Browser Cookies
Understanding how cookies really work requires an understanding of how HTTP works. Cookies transport from Server to Client and back as an HTTP header. The specifications for this header are explicitly laid out in RFC 2109.
When a cookie is sent from the server to the browser, an additional line is added to the HTTP headers (example):
Content-type: text/html Set-Cookie: foo=bar; path=/; expires=Mon, 09-Dec-2002 13:46:00 GMT
This header entry would result in a cookie named foo. The value of foo is bar. In addition, this cookie has a path of /, meaning that it is valid for the entire site, and it has an expiration date of Dec 9, 2002 at 1:46pm Greenwich Mean Time (or Universal Time). Provided the browser can understand this header, the cookie will be set.
When a cookie is sent from the browser to the server, the cookie header is changed slightly:
Content-type: text/html Cookie: foo=bar
Here, the server is made aware of a cookie called foo, whose value is bar.
Breakdown of Cookie Parameters
As we have just seen, a cookie contains more than simply a name and a value. In fact, a cookie has 6 parameters that can be passed to it:
- The name of the cookie,
- The value of the cookie,
- The expiration date of the cookie,
- The path the cookie is valid for,
- The domain the cookie is valid for,
- The need for a secure connection to exist to use the cookie.
Two of these are mandatory (its name and its value). The other four can be set manually or automatically. Each parameter is separated by a semicolon when set explicitly. Here is a detailed description of each.
- Name, Value
The name of a cookie and its value are set simply by pairing them together:
foo=bar
The value of a cookie can also be null, for the purpose of clearing the cookie value:
foo=
- Expires
The expires parameter lets you determine the lifetime of the cookie.
expires=Mon, 01-Jan-2001 00:00:00 GMT
If Expires is not set explicitly, then it defaults to end-of-session. The length of a session can vary depending on browsers and servers, but generally a session is the length of time that the browser is open for (even if the user is no longer at that site).
- Path
The path parameter is potentially the most useful of the 4 optional cookie settings. It sets the URL path the cookie is valid within. Pages outside of that path cannot read or use the cookie.
path=/promo
If Path is not set explicitly, then it defaults to the URL path of the document creating the cookie.
Netscape has identified a bug for VERY old versions of Navigator where the path must be specified if an expiration is specified. Furthermore, this path must be set to "/".
- Domain
The domain parameter takes the flexibility of the path parameter one step further. If a site uses multiple servers within a domain the it is important to make the cookie accessible to pages on any of these servers.
domain=www.myserver.com
Cookies can be assigned to individual machines, or to an entire Internet domain. The only restrictions on this value is that it must contain at least two dots (.myserver.com, not myserver.com) for the normal top-level domains, or three dots for the "extended" domains (.myserver.ny.us, not myserver.ny.us)
IMPORTANT: The server issuing the cookie must be a member of the domain that it tries to set in the cookie. That is, a server called www.myserver.com cannot set a cookie for the domain www.yourserver.com. The security implications should be obvious.
If Domain is not set explicitly, then it defaults to the full domain of the document creating the cookie.
- Secure
The secure parameter is a flag indicating that a cookie should only be used under a secure server condition, such as SSL. Since most sites do not require secure connections, this defaults to FALSE.
See also Browser Cookies