WebReference.com - 2 Ways to Implement Session Tracking (3/4) | WebReference

WebReference.com - 2 Ways to Implement Session Tracking (3/4)

To page 1To page 2current pageTo page 4
[previous] [next]

2 Ways to Implement Session Tracking

URL Rewriting

This is another popular session tracking method used by many. But it has a few bad points associated with it. In spite of that I like to use this method. It doesn't require a lot of understanding to get the work done. URL Rewriting basically means that when the user is presented with a link to a particular resource instead of simply presenting the URL as you would normally do, the URL for that resource is modified so that more information is passed when requesting that resource. I can see puzzled faces trying to make sense of what I just wrote. Read on and things shall get more clear...

I will try explaining URL Rewriting with the same shopping cart example used in the hidden field method. Actually I could have shown simpler examples, but for you to compare the 2 methods I shall take up the same example once again.

Once again assume that a user has searched for some books and he has been presented with a search result that has 2 books listed. It is basically a form with 2 checkboxes, each for one book and a submit button to add any of these book to his cart.

<b>Search results for books</b>
<form method="post" action="serverprogram.jsp">
<input type="checkbox" name="bookID" value="100">Java Servlet Programming<br>
<input type="checkbox" name="bookID" value="101">Professional JSP<br>
<input type="submit" name="Submit" value="Add to Cart"><br>

Now once again suppose the user selects the book named 'Java Servlet Programming' and then clicks on the submit button. This would pass the contents of the form to the server side program called serverprogram.jsp which should read the selected checkboxes and do the necessary processing (i.e. make some arrangements to keep track of the selected books, which basically means implement session tracking). Now suppose the user continues browsing and searches for more books and is presented with a new search result just like in the previous example. For better understanding I shall once again give you the same 2 results as shown in the hidden fields method: the 2 books named 'Teach yourself WML Programming' and 'Teach yourself C++.'

<b>Search results for books</b>
<form method="post" action="serverprogram.jsp?bookID=100">
<input type="checkbox" name="bookID" value="150">Teach yourself WML Programming<br>
<input type="checkbox" name="bookID" value="160">Teach yourself C++<br>
<input type="submit" name="Submit" value="Add to Cart"><br>

You should be able to guess by now what URL rewriting is all about. In the above HTML source, the target for the form has been changed from serverprogram.jsp to serverprogram.jsp?bookID=100. This is exactly what URL Rewriting means. The original URL which was only serverprogram.jsp has now been rewritten as serverprogram.jsp?bookID=100. The effect of this is that any part of the URL after the ? (question mark) is treated as extra parameters that are passed to the server side program. They are known as GET parameters. The GET method of submitting forms always uses URL Rewriting. Now when the serverprogram.jsp fetches the parameters by the name bookID it would be presented with the one that was present after the ? in the URL as well as the newly selected checkboxes by the user in that form.

Consider a general example where a user has selected 2 values, then whenever a program generates a new form the target for that form should look something like:

<form method="post" action="serversideprogram.jsp?name1=value1+name2=value2">

This sort of URL would keep on increasing as more and more values have to be carried on from one page to another.

The basic concept of URL Rewriting is that the server side program should continuously keep changing all the URLs and keep modifying them and keep increasing their length as more and more data has to be maintained between pages. The user does not see anything on the surface as such but when he clicks on a link he not only asks for that resource but because of the information after the ? in the URL he is actually sending previous data to the program.

The disadvantage of URL Rewriting (though it's a minor one) is that the displayed URL in the browser is of course the rewritten URL. Thus the clean simple URL that was seen when hidden fields were used is replaced with one with a question mark (?) followed by many parameter values. This doesn't suit those who want the URL to look clean. Another disadvantage is that some browsers specify a limit on the length of a URL. So once the data which is being tracked exceeds a certain limit, you may no longer be able to use URL Rewriting to implement session tracking; but that limit is generally large enough that you needn't feel afraid to use this method. Do note that actually rewriting all the URLs within your program is not a simple task and requires some experience; also, some APIs may, by default, prohibit you from accessing both POST and GET data simultaneously; thus you should consider combining the two methods only if you are familiar with retrieving both types of data in your server-side language of choice.

In case you are confused with what we have been doing with hidden fields and URL Rewriting, I shall sum it up once again for you. We are trying to learn methods that allow us to carry information from one HTML page to another since by default you cannot pass information from one HTML page to another. So to carry data from one page to another, we are either using hidden fields invisible to normal users or rewriting all the links on a page so that the server side program receives the old as well as new data. Thus we can maintain a session (a connection between multiple pages) for every user.

To page 1To page 2current pageTo page 4
[previous] [next]

Created: March 27, 2002
Revised: March 27, 2002

URL: http://webreference.com/programming/sessions/3.html