Transition from *nix to windows platform is hard..it's high time someone writes "*nix to *dos for dummies". Last day I had to sync two folders and I was searching something similar to rsync in unix.Usually most of my search for tools in windows ends up in a free trail installers.Luckily this time i was blessed. Although not so feature rich as rsync it does the work done .I am talking od xcopy command in windows command promt.
enough of bla bla bla tell how do we sync to folders..
xcopy [source] [destination] \s \d
\s : for subdirectories (similar to -r in *nix) \d : for copying just the folder differences
Last day my friend had a problem...she had to do some extra work with the submit button other than embedding the parameter values to HTTP request. She had to clear the form contents before the form get submitted. So the basic question comes down to...
How do we change the behavior of Submit button of the HTML form ??
HTML form tag contains an intrinsic event attribute called onsubmit. The onsubmit event is fired on the click of the submit button. And the form does not get submitted if the expression returns a false (it gets submitted on all the other cases...whatever scrap U write in the expression)
So the only way to stop the html form from embedding the parameters to the HTTP request is to return a false from onsubmit event function should look something like the code below or something which does the same.
Now what role does the return false do here...Try the code with no return false U will see that the request parameters gets filled with resetted value. Its because the form values get embedded to HTTP request twice..Once on the call of formObj.submit() and the second time after it comes out of the resetFormSubmit button.Thus the next page get called with resetted values.
Most often in web applications we might need to manage information over a series of requests or over a user session. Lets take the classic example of adding 2 numbers. In an ordinary scenarios we will use a form to get the 2 numbers ,send it to the server which adds the no and sends it back to the user as response. The above mentioned computation consists of only one request and response. Now we want the interactions in different way. Instead of sending the first number and second number in a single page we want the first page sending the first number and second page sending the second number and a third page showing the results. These series of request can be called as user session. Now the issue with this design is that the computation spans over 3 request-response round trip. As HTTP is a stateless protocol, second request does not have any relation to the first request for the server. So now the question is how do we build this relation or how do we make the server aware that a series of request comes under one user session.
There are many ways through which the state information over a series of requests can be stored. It can be done by storing the information in the client side(cookies),in the server side(sessions,continuations) carry it with the request and response headers(hidden form fields).
Session management in servlet container
The container maintains memory space for each session which is identified by an id. All the information we need to keep over a session are maintained in this memory space and are maintained as java objects. The unique id known as session id is used to identify which session a particular request belongs to. So obviously session id has to be carried along with the request. The container allots the session object according to session id of the request.
Now its time to get our hands wet...We shall create 3 JSP pages
firstpage.jsp
<.html> <.head> <.title> The first page< /title > < /head > <.body> < .form action="secondpage.jsp" method="get"> First no : <.input type="text" name="firstno" value="0"> <> <.input type="submit" value="Next"> < /form > < /body > < /html >
This page serves as interface to get the 1st no from the user. The page gets the no and puts it in the request object.
secondpage.jsp
<.html> <.head> <.title> The Second page< /title > < /head > <.body> < % String a = request.getParameter("firstno"); session.setAttribute("firstno",a); % > <.form action="resultpage.jsp" method="get"> Second no : <.input type="text" name="secondno" value="0"> <> <.input type="submit" value="Next"> < /form > < /body > < /html >
Similar to the first page this page receives the 2nd no puts it in the request object. In addition, it also adds the value of the 1st no to the session object so that it can be retrieved later.
resultpage.jsp
<.html> <.head> <.title> Result Page< /title > < /head > <.body> < % int b=Integer.parseInt(request.getParameter("secondno")); int a=Integer.parseInt(session.getAttribute("firstno").toString()); out.println(a+b); % > < /body > < /html >
This page processes the input values and gives the result. It retrieves the second number from the previous request object and the first number from the session object.
The above web application should run without any problem in a simple jsp/Tomcat setup. OK if you were success full in running the above web application we can continue with the discussion. Now we have used session object to store our values in it.
One question which used to bother me when I did session programming is how does the request carry the session id. HTTP spec does not contain any information on session, so HTTP has no clue what a session is. So the container have to implement some way to pass the session id from one page to the next. This is what Apache Tomcat a jsp/servlet container does. It checks a parameter with key JSESSIONID in cookie values as well as request URL ,if it finds one it picks up the session object corresbonding to that particular session-id.
My professor use to teach me web technology by doing postmortem on HTTP request/response packets. I have found itthe best way to learn web technology of any level.So lets see the HTTP request headers of our small web application.
Nothing intresting in HTTP response. But if you see the HTTP request you can see teh cookie parameters send to the server with t he first request
CookieJSESSIONID=DF88F04F5D2574711121214DD4AC9FA7
This is how the session managment is done is using cookies. But we are not using sessions in our first page then why do it pass the session id. Its because JSP by default checks weather there is a session existing for that request if it does not exit it creates a session and sets its id in the cookie parameter. That's why we see session id from the first page request. Now lets scan the second pages request and response headers.
If you look at the JSESSIONID value in the cookie header of the request you will find the the same session id value. So the container keeps the session id in the cookie till the session gets destroyed. Now the third request header will also have a similar cookie header parameter. This is how sessions are implemented over cookies. Now try to disable cookies in your browser, you will find that your web application does not work. So how do we do session management when cookies are disabled we can see in the later discussion.
Ohhh...Cookies are disabled..! URL rewritting for yor rescue :)
So what you do when cookies are disabled.You have to find some other way of transferring the session id. I have mentioned in the earlier discussion that Tomcat looks in the cookie as well as request parameters for JSESSIONID parameter. So we have to embed session id in the request URL. Lets try it out.
There won't be any change to the first and the result page they will the same. Remember we do not have problem in adding and removing values to and from the session object but our problem is how do we pass on the session id between two requests. That's why there is no change in the result page.
<.head> <.html> <.title> The Second page< /title > < /head > <.body> < % String a = request.getParameter("firstno"); session.setAttribute("firstno",a); String url =response.encodeURL("resultpage.jsp"); % > <.form action="<"> method="get" > Second no : < type="text" name="secondno" vlaue="0"> <> <.form type="submit" value="Next"> < /form > < /body > < /html >
Here we generate the form action URL from the through encodeURL method. encodeURL first checks whether it could add the session-id in the cookies ,if it cannot add it to the cookies it rewrites the URL adding the session id to the request URL. So if the cookies are disabled in the browser the URL string which is replaced at the form. Lets us examine the request headers of resultpage.
You can notice that there is no cookie header in this particular request.So it is obvious that session id is not passed through cookies. Now if we see the URL at the address bar of the page it would be something like this.
But it won't check whether cookies are enabled or not.
So encodeURL rewrites the URL to embed the session-id parameter to it. The container identifies which session a particular request belongs to by looking at the jsessionid value in the request URL. You might have noticed that unlike the request parameter the jsessionid is embedded in to the URL using a ; delimiter. So jsessionid is not a request parameter in the request.
(Disclaimer: Thes are not my thoughts but was told by Amarnath Raja ,InApp CEO to us during network class...I found it so good that I am writing it down)
IP is an unreliable protocol .It takes its best effort to take the packets to wherever its destined to ...that's it..
We could compare IP to Indian postal system.We send a post mail and we hopes it will reach the receiver (let's assume the postal system takes its best efforts to take it to the receiver).And the postal system works because its unreliable.Lets say tomorrow government decides to make the Indian postal system reliable..Then ,if I have to send a postal mail...I won't be putting the mail in the mail box, but I will be handing over to a person and he should give a receipt of receival for it,then the same procedure has to be followed in each point of transfer of the mail..and there would be at least 5 points where the mail information has to be logged.Think of our postal employees doing the same for the huge no: of mails each day. The system will fail miserable. Just the same way if IP protocol had to made sure reliability in each point of its transfer it would have been a failure.
Now we can see how reliability is attained by using TCP over unreliable IP protocol. Consider I am writing a book consisting of 25 chapters (wow! I am writing a book with 25 chapters..really funny) .I find a publisher and he agrees to print it. We agrees that the content will be sent chapter by chapter over post. I wrote the 1st chapter sends it by post writes the second sends it and does the same for 3,4,5,6 and the publisher receives it (put he doesn't tell me he have got it..why to waste money ). Now something mysterious happens to the 7th packet. I completes the 7th chapter and send to the publisher, but he doesn't receives it.The publisher who is well aware of Indian postal system ignores it and doesn't bother to inform me. While I kept on sending 8th,9th,10th chapters.The publisher receives all these chapters and also receives the missing 7th chapter which he happily keeps it in the correct position .If he had called me for informing the missing of 7th packet he would have wasted a phone call and extra effort of resending the chapter. Now the procedure continues in which 14th chapters gets missed again. The publisher ignores it as usual and continues to recieve other chapters till 20th, now the publisher feels that chapter 14 might have vanished to the black hole of Indian postal system. So he calls me up and tells to send chapter 14 again and sends it. During these time he receives rest of the chapters .When he recieves chapter 14 he puts it in his position . Thus a reliable system of transfer is attained over unreliable postal system. TCP does the same thing. It makes sure the transfer of IP packets in an end to end basis.Inshort it does'nt care about the whareabout of each packets when they are send, but at the end of the session (and even inbetween) checks for missing packets and acts according to it.
