A recipe for cookie management

Integrate an easy-to-use library for client-side cookie handling

By Sonal Bansal, JavaWorld.com, 04/26/02

Page 3 of 6

For example, suppose you want to write a Java client application that interacts with a servlet-based shopping Web application. On the server side, when the servlet first asks the servlet container for a session by calling request.getSession(), the container creates a new session and the server uses a session ID to retrieve the session object on subsequent requests. The server automatically sends this session ID to the client as an HTTP cookie. In subsequent requests, the client sends back the same session ID along with its request. The server uses the ID to locate the right session object for the servlet processing the request. Typically, the code on the client would look like this:

      /* To get cookie. */
      ...
      HttpURLConnection huc= (HttpURLConnection) url.openConnection();
      ...
      InputStream is = huc.getInputStream();
      // Retrieve session ID from response.
      String cookieVal = hc.getHeaderField("Set-Cookie");
      String sessionId;
      if(cookieVal != null)
      {
            sessionId = cookieVal.substring(0, cookieVal.indexOf(";"));
      }
      ...
      /* To send cookie. */
      HttpURLConnection huc= (HttpURLConnection) url.openConnection();
      if(sessionId != null)
      {
            huc.setRequestProperty("Cookie", sessionId);
      }
      
      InputStream is = huc.getInputStream();
      ...

The cookie specification RFC 2965 defines a new header, Set-Cookie2, for version 1 cookies. If we upgraded the server to use the new header, the above code would break. The above code could also not handle multiple cookies. In addition, a version 1 cookie's value can be a quoted string. If the session cookie's value were a quoted string containing a semicolon, that would also cause the above code to break. In short, the code snippet above is not insulated from the cookie version used and is unnecessarily coupled to it.

The above code might be acceptable for a simple application that interacts with only one particular host and path map. But for a more ambitious application, cookie management grows complex when multiple hosts and paths are involved. It would prove painful and unproductive for a developer to implement all the algorithms, security checks, and balances outlined in the cookie specification.

Enter jCookie

To ease some of this heartache, I've developed a general-purpose cookie library christened, predictably, jCookie, which implements the cookie specification. The library minimizes the extra coding and effort required for client-side cookie handling and lets the developer focus on the core application. Other APIs/libraries do exist (for example, HTTPClient from Apache), but they use architectures far removed from the built-in native java.net APIs, thus introducing a new learning curve. My API can be as simple as a method call on existing java.net objects.

You could also use a stripped-down version of jCookie currently under development, called jCookieMicro, on J2ME-enabled mobile devices to create an exciting suite of fat clients that can interact with Web server-based applications.

I now introduce the jCookie API's major actors. I'll start with the two main data structures: