I am unable to figure out what's the actual procedure involved in the practical scenario of applying url rewriting with respect to the case when the cookie is disabled in client's browser.
I am expecting the series of steps(not actual source code) involved in servlet code right from the creation of cookie till application of URL rewriting(using encodeurl() method ) when cookie is found to be disabled?
Step 1 : Browser sends the first request
Step 2 : Web container receives the request.
Step 3 : Web application processes the request, creates a new HttpSession object and stores something in a HttpSession object
Step 4 : Web application writes to the response and commits
Step 5 : Web container writes a session cookie containing the session-id to the response header
Step 6 : Response sent to the client
Step 7 : Browser receives the response
Step 9 : Browser sends second request but this request does not transmit the cookie information since the cookie was rejected
Step 10: Web container receives the request
Step 11: Web application processes the request, tries to look for a session-id but does not find it, hence assumes it is a new request. Now if a HttpSession is needed again, you will get a new HttpSession object. What about the original and information stored earlier in it ? Well, that is gone.
So, in such a scenario if the session-id needs to be reliably transmitted between a server and client and back to the server so that a server-side HttpSession can be reliably used, how can you do that ?
But I was expecting in what respect we inter-mix the steps to program cookie handling and URL rewriting as well.Means just I want to know whether some if condition is involved to check that ok if this cookie is not working then use URL rewriting through encodeurl() method.
How actually we implement it in our code?
Moreover,Even if the same is taken care by the application server,But still we are expected to implement the same in our code.
In my case,I am using Glassfish Server 3.0.
Ok , So you meant to say that we need to explicitly check for the same and it should not be left on the container(Please correct me if I am getting wrong).
But as per my understanding from head first servlets and jsp page number 238,It is container that takes care for all the underlying stuff behind cookie handling and url
rewriting.My confusion is still on the fact that if container seems to take care for everything then why we programmers are expected to do this.
Rather everything should have been abstracted whether cookie creation or url rewriting(means encodeURL() should have been called implicitly in case of servlets),
Programmers should have been able to work directly to get/set attributes in the session.
May be my understanding is not correct n asking a silly question but please clarify me.........Thanks again!!
Joined: Apr 19, 2013
The application server keeps tracking of the session on your behalf you don't need to manage directly this issue.
We can take GlassFish reference session-properties as example.
If you configure
Enables URL rewriting. This provides session tracking via URL rewriting when the browser does not accept cookies.
You must also use an encodeURL or encodeRedirectURL call in the servlet or JSP.
and the client browser doesn't accept cookies, the identifier of the client session will be encoded in de URL (URL rewriting) and the server will track the session looking for this identifier (the server expects this id as a parameter in the request).
But what happens in this scenario (no cookies allowed) if a link or form in some servlet doesn't have the session identifier encoded in the invoked URL?
When the browser send's a request to a URL without the session identifier the server doesn't have a clue to know if this request is related to some previous session.
How to solve that issue?
Encoding the URL invocation with the session identifier.
As carles rightly said everything is managed by web or application server if we want to do programmatically then do as i said earlier.
Whatever scenario carles has mentioned it is appropriate where we will do url rewriting in any case.