WebReference.com - 2 Ways to Implement Session Tracking (3/4)
2 Ways to Implement Session Tracking
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> </form>
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> </form>
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
This is exactly what URL Rewriting means. The original URL which was
serverprogram.jsp has now been rewritten as
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 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.
Created: March 27, 2002
Revised: March 27, 2002