|
Recipes for Cookie Management in J2SEs Tiger and Mustang
by Anghel Leonard
As you probably know, using cookies can be a very handy technique in Web client/server applications. Many seemingly complicated tasks can be quite easily accomplished using cookies. You can monitor user activity, determine the amount of time spent on a site, keep sessions alive, pre-populate forms, manage links, etc. This is why Java offers strong support for sending, receiving, and managing cookies—and when I say Java, I mean J2SE and J2EE.
This article focuses on cookie support in J2SE. You'll learn different methods of receiving and processing cookies and how to create and send new ones. You'll also see how to implement the abstract CookieHandler class in J2SE Tiger and how to use its default implementation in J2SE Mustang.
A Brief Introduction to Cookies Theory
Generally, when a user accesses a Web page, the server responds not only with the requested resource, but also with small pieces of information called cookies. This information can represent almost anything (information about the user, about sessions, about ids, about forms fields, etc.) and will be useful only if their browser is set to support cookies. The next time the user connects to that same resource, the server will receive and process the cookies to save time or just to "amaze" the user with its knowledge. As you can see, this technique permits servers to hold information about a user on the client machine. A big reason for using this approach has to do with physical space—obviously a server can't hold all the cookies for all its clients—that would necessitate a huge hard disk. Further, it would be much too time consuming to find the right cookie for the right client amongst so many.
Cookies come in two flavors:
- Permanent Cookies: These remain on the client machine after the user leaves the Web page.
- Session Cookies: These are destroyed after the user leaves the Web page.
Both types of cookie are name=value pairs (remember the .properties files). Pairs are separated by ";" and a white space. After the server creates a cookie, it uses the HTTP protocol to send the cookie to the client. To do this, the server fills up the HTTP response with the "Set-Cookie" header. Here's the syntax for sending a cookie:
Set-Cookie: name=value; expires=date; path=path; domain=domain; secure
The name=value pair is the "clean" information that you want to persist over time. The source of a cookie is specified by the domain and path. In time, a cookie will expire and be deleted on the date specified by expires (permanent cookie). If expires is not set, the cookie will expire when the current session dies (session cookie). The expires value look like this:
E, dd-MMM-YYYY HH:MM:SS GMT
E, dd MMM yyyy HH:MM:SS GMT
Notice:
The process is reversed for sending a cookie from the client to the server, using the "Cookie" header:
Cookie: name_1=value_1; name_2=value_2 ...
Notice:
- A cookie overrides another cookie if it has the same
name and path.
- A cookie gets added to another cookie if it has the same
path but a different name.
- When you send more than one cookie, priority is determines by the cookies' paths; the longer path has the higher priority.
Click here for more details about cookies.
New on the Java Boutique:
New Review:
Time Management Made Easy with the Quartz Enterprise Job Scheduler
Why not just use the Java timer API? This open source scheduling
API boasts simplicity, ease-of-integration, a well-rounded feature
set, and it's free!
New Applet:
Reverse Complement
Reverse Complement is a simple applet that converts DNA or RNA
sequences into three useful formats.
Elsewhere on internet.com:
WebDeveloper Java
Lots of Java information on webdeveloper.com
WDVL Java
Thorough Java resource at the Web Developer's Virtual Library.
ScriptSearch Java
Hundreds of free Java code files to download.
jGuru: Your View of the Java Universe
Customizable portal with online training, FAQs, regular news updates, and tutorials.
|
