Cookies and Sessions

HTTP is, by itself, a stateless protocol, which means that it "has no memory". This, in turn, means that as you browse from one page to another, there is no "connection" of any kind between the last page and the current page, or between the current page and the next page you go to.

This state of affairs led to problems with, among other things, on-line commercial activities like keeping track of what's in a buyer's "shopping cart", for example.

There are essentially two widely used methods of giving our web pages some memory:

Cookies

A cookie is a small file (often text but now, in Firefox at least, an SQLite file) that can be sent from a web page to a browser and stored on a client machine. When the browser later returns to that web page, the browser will send that cookie to the server hosting that web page, where the information in the cookie can be used to "personalize" the visit.

Sessions

A session is a file on the server identified by a cookie ID reference sent from the client.

Advantages of cookies:

1. Can have a long lifespan, so your data "works" when the client comes back the next day.
2. Can be accessed on the client side via JavaScript.
3. Also works if you have a server "cluster".

Disadvantages of cookies:

1. Can be altered by the user.
2. Limited in size (4kb).

Set a cookie with the setcookie() function, which has six parameters:

1. string name (name of the cookie)
   Cookie access: $HTTP_COOKIE_VARS (old variable), but now use $_COOKIE["name"]
2. string value (value of the name variable)
3. int expire (expiration time)
   -- no time ==> expiry when browser closes
   -- time()+86400 ==> 1 day
4. string path (sets the path to a directory where the cookie will be active)
   -- "/" ==> all files on the server (this is the default)
   -- "/some-directory/" some-directory and its subdirectories
5. domain
   -- Cookies are valid only for host and domain that set them.
   -- Example: mail.yoursite.com makes it available there but not for
   www.yoursite.com (for e.g.), but .yoursite.com ==> everywhere
6. int secure
   -- 0 ==> http or https
   -- 1 ==> https only

Advantages of sessions:

1. Cannot be altered by the user, so much more secure.
2. Good for transient data, like an on-line shopping session.
3. Data doesn't need to be transmitted with each page.
4. Can be any size you want.
5. Saves on bandwidth because only ID reference code passes from client to server.

Disadvantages of sessions:

1. Do not work across a server "cluster", unless you take extra steps, like storing your session information in a database.

Notes

1. The first parameter of setcookie() is required, the rest are optional, and only the first three are used most of the time.
2. Browsers can be set to reject or filter cookies.
3. A single host can request acceptance of up to 20 cookies to be stored on a user's browser.
4. Cookies are "header data", as opposed to "body data", and since HTTP requires all header data to be sent before any body data, page cookies must be sent before any part of the page body.
5. Cookies are sent to the server each time a user visits a page, so if a cookie is set in a script, it does not become available till your user visits the next page (or hits refresh).
6. Cookies can be cleared manually by choosing a browser option or by deleting files (if you know where they live).
7. The best way to delete a cookie is to use the same setcookie() call that created it, except for a time that is in the past. A call to setcookie() with just the name parameter set is supposed to work as well, but may not always do the job.