HTTP is "stateless" -- by itself, it doesn't remember any previous accesses to a Web site.

For many uses of a Web site, however, there are many accesses -- for example, logging in, selecting purchases, and checking out each involve at least one access to the site. How can the site provide continuity for multiple accesses?

A session is a sequence of related accesses to a Web site. The PHP programmer can decide what the sequence should be. For example, it might be everything a user does between logging in and logging out.

Note that the book never really says what a session is (or a transaction). In both cases, the programmer has to decide.

A session is a sequence of related accesses to a Web site. Their relationship needs to be recognized by the Web site in order to provide the right functionality to the user. For example, a user that is shopping at an e-commerce site may purchase a whole series of items, and all of them should be included in his order for the Web site to be operating properly.

A transaction is similar: It is a sequence of updates to a database that must be treated a single update in order to be completed correctly. For example, a transfer of money from one account to another involves at least two updates to a bank database, but all updates must be completed and committed for any of the updates to be correct.

The common property is that both require multiple actions to be treated as a unit. However, there's no magic formula that says what should be a transaction or what should be a session. It's your responsibility, as a programmer to decide.

The session data is maintained on the server, in a configured directory. On Mac OS X, the default is /var/tmp. The session variables, which are set in the superglobal array $_SESSION while a script is running, are serialized and placed in the file. Serialization is a process that makes it possible to transfer a variable or object from one program or even computer to another.

A cookie is a small file that is left on the client (stored by the browser). A cookie identifies a session id, so that the session file stored on the server can be accessed to recover the session variables. It's identified by the URL, and when you access a Web site, the browser checks if you have relevant cookies. If so, it provides them to the site. This allows the site to maintain information between accesses. There can be both session cookies, which are transient and deleted at the end of a session, and permanent cookies, that maintain information such as username and password between sessions.

From the Netscape cookie specification:

The designers' paradigm for sessions created by the exchange of cookies has these key attributes:

      1.  Each session has a beginning and an end.

      2.  Each session is relatively short-lived.

      3.  Either the user agent or the origin server may terminate a session.

      4.  The session is implicit in the exchange of state information.

The HTTP protocol provides for a session header "Set-Cookie:". The header value consists of a set of attribute-value pairs (convenient for storing in an associative array).

You can look at the cookies that your browser is storing. There are different methods for different browsers. You may get some surprises (I did). Cookies from 2o7.net indicate that Adobe is tracking you. There's a 5min.com site that seems weird and may be a spam site -- it's hard to tell what it is.

A session ID is assigned at the beginning of a session, and passed as part of the URL (GET) or the Web page (POST). It enables the server to store data for a single user between different accesses to the Web site, using a database table or an associative array. In both cases, the data is identified by the session id. Cookies can be also just store a session ID, and the session information is actually maintained on the server.

bool session_start ( void )
Create a session or resume the current one based on a session identifier passed via a GET or POST request, or passed via a cookie.

Examples:

1. test_session.html, test_session.php
   Explanation: Every time you click submit, you invoke test_session.php again. Note that the session id is always the same.
2. count.php
   Explanation: Every time you click "Next", a counter is incremented. When you click "Quit", the counter is unset (see the code).

string session_id ([ string $id ] )
Get or set the session id for the current session.
Example: test_session1.php, first_session.php, second_session.php
Significance: We can run multiple sessions with the same user simultaneously (should we need to).

void session_write_close ( void )
Alias: session_commit()
End the current interaction with the session and write the session data. (Note: PHP documentation says "end the session", but the session still exists and can be restarted. The effect is that further actions on the session variables in this script have no permanent effect. The session variables are changed in the current script, but the changes are not registered with the committed session. This frees us up to start a second session.)
Example: test_commit.php
Explanation: The commit doesn't eliminate the session variables, but it doesn't save them for the next time session_start() executes.

bool session_destroy ( void )
Destroys all of the data associated with the current session. It does not unset any of the global variables associated with the session, or unset the session cookie. To use the session variables again, session_start() has to be called.
Example: test_destroy.php
Explanation: The session variables disappear and the session file is empty after the destroy.

Questions:

1. Does setting the session id start a new session? Note that test_session1.php has both a session_id(<string>) and a session_start() for each session.
   See test_session1a.php. The second start_session() has been commented out.
   Also, see test_session1b.php. Both start_session() commands have been commented out.
   All php programs behave exactly the same.
   Conclusion: It appears that session_start() is unnecessary if you are setting the session id. It is only needed if the system sets it for you.
2. If you start a new session without committing the old one, what happens?
   See test_session1c.php. The commit also seems to be unnecessary.
3. What happens if you commit, but don't start a new session?
   See test_commit.php
4. What happens if there are multiple active sessions? Which session file is used? What are the session variables?
   Run test_default.php after running various other scripts.

Notes:

1. Because of the uncertainties illustrated by the examples above, it will always be a good idea to use session_destroy or $_SESSION=array(); at the end of a session.
2. If you try to provide more than one session at a time, you need to figure out how session id's work!

Remember previous activity:

• A user has logged in. This lets us permit various parts of the Web site to the user. Also, it lets us determine exactly what he can do.

• Limit user accesses. For example, the New York Times allows 5 visits to their site a day. You can get around this by deleting your cookies. How do you think they are implementing this?

• Allow and record user activities. A user can add things to a shopping cart, to be checked out. A user can create documents, to be emailed or stored.

Exercises.

1. How would you manage user logins? How would you log a user out?
2. How would limiting user accesses work?
3. How would you implement a shopping cart?

1. How does a server know that a session has started?
2. What is a session?
3. Why would you use a session? How would you decide when a session should start and when it would stop?
4. What are three things cookies used for?
5. What is a session identifier?
6. Know how the session commands work.