|
How does a cookie really work?
Breakdown of Cookie Parameters
How do cookies end up on my hard drive?
What are all those entries in my
cookies.txt file?
Where does MSIE keep its cookies?
Are cookies Year 2000 Compliant?
How does a cookie really
work?
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.
[Back to Top]
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 "/". For more
information, browse Netscape's Cookie Spec at:
http://www.netscape.com/newsref/std/cookie_spec.html
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.
[Back to Top]
How do cookies end up on my hard
drive?
After a cookie is transmitted through an HTTP header, it is stored in
the memory of your browser. This way the information is quickly and
readily available without re-transmission. As we have seen, however, it
is possible for the lifetime of a cookie to greatly exceed the amount of
time the browser will be open.
In such cases, the browser must have a way of saving the cookie when you
are not browsing, or when your computer is shut off. The only way the
browser can do this is to move the cookies from memory into the hard
drive. This way, when you start your browser a few days later, you still
have the cookies you had previously.
The browser is constantly performing maintenance on its cookies. Every
time you open your browser, your cookies are read in from disk, and
every time you close your browser, your cookies are re-saved to disk. As
a cookie expires, it is discarded from memory and it is no longer saved
to the hard drive.
What are all those entries in my
cookies.txt file?
The layout of Netscape's cookies.txt file is such that each line
contains one name-value pair. An example cookies.txt file may have an
entry that looks like this:
.netscape.com
TRUE / FALSE 946684799 NETSCAPE_ID
100103
Each
line represents a single piece of stored information. A tab is inserted
between each of the fields.
From left-to-right, here is what each field represents:
domain - The domain that created AND that can read the variable.
flag - A TRUE/FALSE value indicating if all machines within a
given domain can access the variable. This value is set automatically by
the browser, depending on the value you set for domain.
path - The path within the domain that the variable is valid for.
secure - A TRUE/FALSE value indicating if a secure connection
with the domain is needed to access the variable.
expiration - The UNIX time that the variable will expire on. UNIX
time is defined as the number of seconds since Jan 1, 1970 00:00:00 GMT.
name - The name of the variable.
value - The value of the variable.
[Back to Top]
Where does MSIE keep its
cookies?
Microsoft keeps its cookies in different locations, depending on the
version of explorer and Windows you are using. The best way to find it
is to use the Windows "Search" feature an look for the
"Cookies" folder. More information can be found here.
Although the location may be different, the format is the same. Each
individual domain's cookies are stored in their own file, along with the
username that accessed the site. For example, if I went to Yahoo.com, I
would get a cookie that is stored in the file dwhalen@yahoo.txt.
Note that the username is not sent with the cookie. See Cookies
FAQ - General for more information.
[Back to Top]
Are cookies Year 2000 Compliant?
There is no date-specific restriction on the HTTP header used to
transmit cookies. In fact, the only determining factor in whether a
cookie will be accepted is the programming of the client receiving the
cookie.
The major browsers do not have an issue with this. Cookies with
expiration dates set with 2-digit or 4-digit years are understood
properly. Naturally, it's always advisable to use 4-digit years when
setting cookies.
[Back to Top]
Copyright ©1997-2002
David Whalen. This document is provided "as is" without any
guarantees or warranty. Although the author has attempted to find and
correct any errors or mistakes he, and everyone who contributed to it,
are not responsible for any damage or losses of any kind caused by the
use or misuse of information in this FAQ. The author is under no
obligation to provide service, corrections, or upgrades to this FAQ.
The following is legal information and refers to all the information in
this document. This information pertains to all use of the FAQ
worldwide. All specific names included in the package are registered
trademarks and are hereby acknowledged. Any other trademarks not
mentioned in the FAQ are still hypothetically acknowledged.
No portion of the document may be separated and distributed
separately without the written permission of the author, David Whalen.
The document can not be included in any publication, such as, but not
limited to: magazines, books, newspapers or newsletters, without the
written permission of the author. The document can not be
included in any software compilation using media such as, but not
limited to: CD-ROM, tape backup, optical disks, hard disks or memory
cards, without the written permission of the author. The document
can not be recompiled, modified or not, and distributed without the
written permission of the author. Visitors are encouraged to send
submissions and error fixes to the author, but the author is in no way
obliged to utilize these enhancements or fixes. In the event of
ambiguity or omission within this notice, all rights and ownership are
retained by the author.
|
