The Java Cookie class

The Servlet API includes a Cookie class to wrap up the contents of a cookie plus a few attributes. There are generally two stages to using a cookie: first, at some point, we will want to ask the client set a cookie. Then, at some later stage, we'll want to read the value of the cookie. Once we ask a client to set a cookie, then the client should send us back that cookie in any request to the domain/path that the cookie is defined for.

Setting a cookie

To ask the client to set a cookie, we create a Cookie object and then add it to the HTTP response that our Servlet sends back:

public void doGet(HttpServletRequest req, HttpServletResponse res)
    throws ServletException, IOException {
  // read from the request the uesr's desired result per page
  Cookie ck = new Cookie("prefResultsPerPage", resPerPage);
  res.addCookie(ck);
  // now write response as normal...
}

The constructor takes the essential parameters of a cookie: a name and value. There's no absolute limit to the length of either, but the cookie specification¹ only recommends 4K as the minimum requirement for the length of a cookie, and it appears that some browsers have indeed imposed this rather meagre limit. According to the specification, the 4K limit includes name, value plus the attributes (in the format sent in the HTTP header). In other words, the answer to the question "what is the maximum length of a cookie?" is "fairly short, but it's impossible to give a precise maximum that applies to all cases and/or all browsers".

ck.setMaxAge(30 * 60);

Cookie ck = new Cookie(...);
ck.setPath("/users/");
ck.setDomain(".mydomain.com");

How to delete a cookie

To tell the client to delete a cookie "now", add it to the response as above, but set its maximum age to zero. If you want the client to delete the cookie at the end of the current session, then set a negative maximum age (such as -1), though in fact this is the default behaviour.

"Secure" cookies

Cookies have a secure flag, indicating that the cookie should only be sent over a secure channel. The rationale is as follows: supposing that we set a session ID cookie in response to the user logging in over a secure connection. Since the session ID is what to the server "represents" the user name and password, we don't want that session ID to ever be sent over an insecure connection and be vulnerable to eavesdropping. Setting the secure flag asks the client not to ever send that cookie over an insecure connection. In theory, "secure" and "insecure" are left to the interpretation of individual clients, but in practice "secure" means "HTTPS connection".

Call setSecure(true) on a Cookie object in order to mark the corresponding cookie as secure.

Of course, setting setSecure() doesn't magically turn insecure connections into secure connections. In order to set up a secure connection, you have to make sure that the client is making an HTTPS request and that your server is set up to deal with HTTPS.

Next: reading a cookie

Once we have set a cookie, then on subsequent requests to the Servlet, we will probably want to read the cookie value back.

1. See RFC 2965 for more information.