The Mobile Developer

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.

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.

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 it requires.

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.

If you can't use cookies for session tracking, 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:

http://www.foo.com/servlet/myapp/page.html

Then with URL rewriting enabled it might return this instead:

http://www.foo.com/servlet/myapp/page.html?sessionid=83747783

or perhaps:

http://www.foo.com/servlet/myapp/page.html;sessionid=83747783

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).

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 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.