21.6 Java4560: session tracking using url rewriting  (Page 2/6)

The same holds true for session tracking using URL rewriting. Session tracking using URL rewriting provides only limited persistence. While this mayseem like a major downside, there is at least one upside for both schemes.

Comparison with cookies

A future module will explain session tracking using cookies. Cookies probably provide the most commonly used scheme for session tracking because cookies canprovide persistence over long periods of time. However, there is also a downside to cookies. The user can disable cookies in the browser, which completelydefeats the use of cookies for session tracking.

Therefore, if your online game uses cookies for session tracking and the user disables cookies, then you game won't work in that browser. As far as I know, itis not possible for the user to prevent session tracking using either hidden fields or URL rewriting.

A servlet and a JSP

I will explain two different programs that accomplish the same objective in this module. Oneof the programs is a servlet. The other program is a JSP. You probably need to understand the servlet version in order to really understand the JSP version.

The URL window with hidden fields

If you observed the URL window in your browser while running the hidden-field servlet in the earlier module , you probably noticed that after several cycles, the window containing the URL looked something like Figure 1 .

Figure 1 - The URL for hidden fields.

What you see in Figure 1 is the standard way that HTML forms pass parameters to their HTTP servers using the GET method.

A parameter string

When the user clicks the submit button, a string containing the names and values (name::value pairs again) for all of the fields is created and concatenated onto the URL. The string of parameter values is joined to the URLwith a "?" character. The individual parameters are separated from one another with the ampersand character.

Recall that for the servlet in the earlier module , the field named firstName was the visible field in which the user entered a name. The fields named item were hidden fields that were created and populated with historical data when the servlet generated the HTML form for return to the client. You cansee parameters with both of these names in Figure 1 .

The parameters are accessible by the servlet

It doesn't really matter how these parameter names and values come to be concatenated onto the URL. As far as the servlet is concerned, their values areaccessible using the methods getParameter() and getParameterValues() .

This suggests that in some cases, it might be beneficial for the servlet to save the historical data by concatenating it onto a URL referenced in the HTMLpage before returning the page to the client. That is one of the ways that URL rewriting can be used to implement session tracking.

Discussion and sample code

As I mentioned earlier, I will present a servlet and a JSP program where both are designed to achieve the same objective. This will make it possiblefor you to compare the two programming styles.