Newsletter sign-up

View all newsletters

Sign up for our Enterprise Java Newsletter

Enterprise Java

Take control of the servlet environment, Part 3

Beware of the cookie monster

By Thomas E. Davis and Craig Walker, JavaWorld.com, 07/26/01

In Part 1 of "Take control of the servlet environment," we introduced the Rudimental Servlet Extension Framework (RSEF) and explained how it works. In Part 2, we implemented a concrete example that allowed you to take control of your sessions (away from the servlet engine) and store them into a database. In our concluding article, we'll discuss a nasty little cookie pitfall, how it can bite you, and how you can use RSEF to avoid it. Then, once we have better control over our cookies, we'll use them to implement a new twist on our session solution from last month.

The trouble with cookies

Magical little pieces of data, cookies help a Web server identify and remember a particular Web browser. The first time a browser connects to the server, the server says, "Hi there! Here's a cookie for you, but don't eat it! Show me this cookie each time you come back to visit." Then, during all subsequent browser-to-server requests, the server can identify the visitor.

Behind the scenes, cookies are mapped to domains. Domains are, for the purposes of this discussion, Website addresses. For example, the domain for http://www.yahoo.com/ is www.yahoo.com. Actually, yahoo.com is the domain, and www is a subdomain; herein lies the problem. Cookies are actually mapped to the full path -- domain and subdomain -- and subdomains can go deeper than one layer, for example http://us.f36.mail.yahoo.com/ or http://lw3fd.law3.hotmail.msn.com/.

But why does this present a problem? Suppose you have a visitor surfing your Website at http://www.rudiment.net/. Any cookies that you send to the browser will map to www.rudiment.net. For the purposes of organization, you have segregated a portion of your site at the address http://members.rudiment.net/. As a visitor bounces back and forth between the two addresses, the server cannot share the cookie values. This behavior resembles scope or namespaces in programming. A cookie named "session" might exist in both the www cookie and the members cookie under the rudiment.net domain, with each instance being unique.

But wait, it gets worse. Suppose the user types http://www.members.rudiment.net/ into his or her browser. Assuming that you have this subdomain mapped to http://members.rudiment.net (or your DNS is configured for wildcards) and your Webpages use relative links (both topics beyond the scope of this article), the cookies are now written to the www.members version of the rudiment.net domain instead of the normal www, as the figure below illustrates.

Cookies map to domain and subdomain

Two major problems result:

First, you cannot access any data that you write to the browser at the www.members subdomain if the visitor returns later to the members address. When the browser passes a cookie back to the server, it passes only the values stored in the lowest-level subdomain of the request.

 

About Us | Advertise | Contact Us | Terms of Service/Privacy

Copyright, 2006-2008 Network World, Inc. All rights reserved.