ServersSession Tracking With Apache Page 3

Session Tracking With Apache Page 3

ServerWatch content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.

Choosing an Expiry Time

The final directive you may want to configure is the expiry time for the cookie. The expiry time helps determine the difference between “sessions” of the same user. As long as the user keeps using the Web site, the session will be updated, but when he leaves the site, the cookie will eventually expire and a new one (and corresponding session ID) will be generated on his next visit the site.

You must therefore configure the expiry time to enable a user who visits the site to take breaks, if necessary, while he answers the phone or attends a short meeting. Choose a timeout period suitable to identify the difference between visits to your site. For example, for a news or shopping site, a timeout of an hour would probably suffice, but an intranet site intended to be used all day might benefit from a 12-hour timeout.

Table of Contents
Tracking Progress
Adding mod_usertrack to Your Apache Installation
Enabling Tracking
Choosing an Expiry Time
Configuring the Log
Analyzing the Results
Dynamic Solutions
The Performance Trade Off

The default option is for the cookie to remain active until the current browser session is terminated (i.e., when the user quits the application). Alternatively, you can set a specific time either in seconds or by using an explicit declaration in years, months, weeks, days, hours, and minutes (e.g., “2 weeks 7 days 9 hours”). If you use this format, be sure the directive parameter is enclosed in double quotes.

The CookieExpires directive configures this option. To set a timeout in seconds, specify the number of seconds as an integer:

CookieExpires 3600

The above sets an expiry time of an hour.

Configuring the Log

The final configuration directive is where the information will be logged. Our preference is to record this information as part of the standard access log. The %{Cookie}n log field contains the cookie information (hostname and cookie ID), which can be added to the standard common log format definition:

LogFormat "%h %l %u %t "%r" %>s %b %{Cookie}n" common

We recommend putting the cookie information at the start of the log, rather than the end:

LogFormat "%{Cookie}n %h %l %u %t "%r" %>s %b " common

Alternatively, you can configure a customized log for cookie data by putting a CustomLog directive in the site definition:

CustomLog logs/clickstream "%{cookie}n "%r" %t"

Analyzing the Results

Once the user track information is configured, try using the site and viewing the log. The log below is a standard access log with the cookie detail added. - - [19/Jan/2005:18:26:24 +0000] "GET /mcslp.css HTTP/1.1" 
304 - - - [19/Jan/2005:18:26:23 +0000] "GET / HTTP/1.1" 200 7970 - - [19/Jan/2005:18:26:24 +0000] "GET /weather/images/symbo
l_10.gif HTTP/1.1" 200 2019 - - [19/Jan/2005:18:26:24 +0000] "GET /weather/images/symbo
l_24.gif HTTP/1.1" 304 - - - [19/Jan/2005:18:26:26 +0000] "GET /contacts/ HTTP/1.1" 
        200 14671

It’s easy pull out the necessary information from the log to identify which pages this individual has been viewing — we now have a suitable tag (the unique cookie ID number) to start summarizing and reporting information. The basics of log reporting have been covered in previous articles.However, at its most simple, extract the cookie ID (as shown here), and then use it as another key for summarizing log data.

>> Dynamic Solutions, Performance Trade Off

Get the Free Newsletter!

Subscribe to Daily Tech Insider for top news, trends & analysis

Latest Posts

Related Stories