CSE 134A Lecture Notes, October 15, 2001

CSE134A LECTURE NOTES

October 15, 2001

ANNOUNCEMENTS

The deadline for the current project is next Monday, October 22. The part where you build your own server for checking spelling is canceled. We'll revisit that topic later in the quarter.

SESSION VARIABLES

[As stated before, the information here is taken from Session Handling with PHP 4 by Tobias Ratschiller, available at http://www.zend.com/zend/tut/session.php?print=1]

The session_register() command allows you to create variables which are stored throughout the session. All variables you want to preserve across page requests must be registered to the session library with the session_register() function.

This is an example of a counter that increments for each page of a session. You would put this code in each script that might be executed as part of the session.

session_start();
print($counter);
$counter++;
session_register("counter");

Note that session_register() takes a string that is the name of a variable as argument, not the variable itself. The examples show the difference clearly.

It's as easy to use session variables in a script as it is to use GET/POST variables. If you register a variable named "foo" then$foois accessible automatically after calling session_start(). You can also register objects as session variables.

CONTINUING A SESSION

PHP 4 sessions support the following methods of passing the session ID from one web page to another:

Cookies (default)
As GET variables placed by the script author in the URL
As GET variables by automatic URL rewriting

Cookies are the default way to pass the session ID between pages. With the second and third methods the URL is similar to

script.php3?<session-name>=<session-id>.

You can create a URL like this explicitly using the PHP global constant named SID:

printf('<a href="script.php?%s">Link</a>', SID);

In the above, %s is a format that controls how the value ofSIDis printed.

Automatic URL rewriting is a new feature of PHP 4. To enable it, PHP must be compiled and installed with the option --enable-trans-id . Then the session ID in the GET form is added automatically to all relative links within PHP-parsed pages.

Automatic URL rewriting should be used with caution on high-performance sites. PHP has to analyze whether each page contains relative links, then add the ID to the links. This introduces a performance penalty. Cookies are set only once, and avoid the overhead of URL rewriting.

ENDING A SESSION

Session ending is not automatic, because it is difficult for the system to tell when the user is finished with his/her session.

The programmer can force a session end with the command session_destroy().
The default cookie lifetime is 0, meaning that the cookie is deleted and the session ends when the user closes the browser. You can influence the cookie's lifetime with the configuration value lifetime.
The gc_maxlifetime configuration directive specifies how long after the last access to each session its data is destroyed. This happens even if the cookie still exists on the client side.

You can use session_unregister() to remove variables from the session, for example, when the user removes a product item from the shopping cart.

GARBAGE COLLECTION

Cleaning up old sessions (called "garbage collection") on every page request would cause considerable overhead. Therefore, with gc_maxlifetime, you should use gc_probability. This specifies with what probability the garbage collection routine is invoked. If gc_probability = 100, the cleanup is performed on every request. By defaultgc=1meaning old sessions will be removed with a probability of 1% per request.

If you pass the session ID via GET or POST instead, you need to pay special attention to the garbage collection routines. Users might bookmark URLs containing the session ID, so you need to make sure that sessions are cleared frequently. If the session data still exists when the user accesses the page with the session ID at a later time, PHP simply resumes the previous session instead of starting with a new session, which may not be your intention. A value of 10 to 20 for gc_probability would better fit this scenario than the default value of 1.

You might ask yourself why PHP allows you to specificy a probability (gc_probability) which determines when garbage collection will occur, rather than a function which cleans up every n times. Using the probability function means that the server does not have to store and update a global counter, which translates to faster execution.

STORING SESSION DATA

To read and save session data, PHP uses storage modules. There are currently three storage modules available:

Files. By default, PHP creates a text file named after each session ID in /tmp. The content of this file is a serialized representation of all the session variables.
mm. For higher performance but lower reliability, the mm module stores the data in shared memory and is therefore not limited by the hardware I/O system.
User. This mode uses "callback functions" that the programmer writes the code for.

With callbacks you can store sessions however you want: in a database like MySQL, in XMLm, on a remote server.