The Mobile Developer
by Eric Giguère
Wireless Session Tracking
Summer's almost over, so it's time to start writing this
column again. Today's topic is about how to implement
wireless session tracking.
What is a session?
A session, of course, is a way of grouping individual
and seemingly unrelated HTTP requests as if they
came across a single connection between server and
client. HTTP is really a connect-and-release protocol:
the client makes the connection, sends its request,
waits for the response, then disconnects. This allows
the server to service many more clients than would be
possible if all the clients kept their connections
open. However, it also means that a session is no
longer defined by a single connection, which is normally
the simplest way of tracking who is talking to the server.
Note that session tracking is a problem for any
client that uses HTTP. This includes conventional
web browsers as well as cellphone-based microbrowsers.
If we can't depend on the connection themselves to
provide session tracking, how do we do it? There
are two techniques in current use that can be used
with wireless microbrowsers: cookies and URL rewriting.
Session tracking with cookies
A cookie is a named piece of data that a web server
sends back to the client and which the client stores
and sends back to the server the next time it makes
a request from that server. The data is a simple
text string and can't be very long. A cookie also
has an expiry date, after which the client no longer
sends it to the server and removes it from its internal
database. A session-only cookie
expires automatically when the browser shuts down,
while a persistent cookie expires at a date
and time set by the server.
Using a cookie for session tracking is fairly simple.
When the server sends back a response, it adds a cookie
to the response. The value of the cookie contains the
session information that the server needs to track.
Usually it's a value that maps onto an internal data
structure maintained by the server. Whenever the client
sends a request, the server looks for the session
cookie and uses its value to look up the session information
Your web server may provide automatic cookie-based session
tracking, so you may not even have to do anything yourself.
The Java servlet API, for example, defines an
HttpSession class that your servlets can
use to store information on a per-session basis.
If you're using cookies with wireless devices, remember
that there's a gateway between you and the device. The
cookies will actually be stored at the gateway, not on
the device, and the gateway may not store certain types
of cookies. For example, the Phone.com gateway (in
common use in North America given that most cellphones
here use the Phone.com browser) only
stores persistent cookies. Or the gateway might not
even accept cookies.
Session tracking with URL rewriting
an alternative is use URL rewriting. With URL
rewriting you basically encode the necessary
session information into any URLs the server
generates. In other words, if the server
would normally return this URL:
Then with URL rewriting enabled it might
return this instead:
or something similar. Basically, the information that
would be stored in a cookie is added to the URL. When
a request comes in from the client the server looks
for this special session information in lieu of a cookie.
Again, if you're using Java servlets, the servlet API
provides facilities for letting the web server rewrite
URLs for you to include the necessary session information.
Otherwise you have to do it yourself.
When adding session information to a URL, be sure to
use only alphanumeric characters and the equals character.
Using special characters like a dollar sign ('$') can
cause problems with microbrowsers (which will interpret
a '$' as the beginning of a variable substitution).
Other session tracking techniques
There are other session tracking techniques that
you can use. If the client and the server can
communicate using secure sockets (SSL), for example,
then the web server can use the secure link to
define a session. For wireless devices this
means SSL between the gateway and the server,
but it amounts to the same thing.
Another alternative for wireless devices is to
use the unique device information that may
be available. For example, the Phone.com
gateways include a x-up-subno header
in their HTTP requests that uniquely identify
the device making the request. Palm VII's
can use the %DEVICEID% escape to
have the Palm.net gateway insert
a device ID. Other gateways may have similar
capabilities. If you need to support both
wired and wireless devices, however, be aware
that you can't get this kind of information
from conventional web browsers.
Which technique to use?
Which technique you use depends of course
on what kind of clients you're talking to.
URL rewriting leads to ugly-looking links,
though, and it should really be your
choice of last resort.
Eric Giguère is the author of the upcoming
2 Micro Edition: Professional Developer's Guide and the
Database Programming: The Complete Developer's Guide.
He works as a developer for iAnywhere Solutions, a subsidiary of Sybase, Inc.
Visit his website at www.ericgiguere.com
or send him mail at firstname.lastname@example.org.