aspose file tools*
The moose likes Servlets and the fly likes cookies and URL rewriting Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Servlets
Bookmark "cookies and URL rewriting" Watch "cookies and URL rewriting" New topic
Author

cookies and URL rewriting

ankur rathi
Ranch Hand

Joined: Oct 11, 2004
Posts: 3830
Hi,

I am confuse in two ways of session handlling: cookies, URL rewriting.

Suppose, we are attempting both the ways for keeping sessions (setting cookie into response and appending session Id to URL):

case 1 when browser accept cookies, why browser adds session Id to URL???, it already added cookies into request and it is sufficient to keep session...

case2 when browser don't accept cookies, browser only adds session Id to URL, on the other side server try to get cookies first and if it is not found then starts new session...How we are keeping session???

Please help.

Thanks.
[ December 05, 2005: Message edited by: rathi ji ]
Adeel Ansari
Ranch Hand

Joined: Aug 15, 2004
Posts: 2874
Originally posted by rathi ji:
case2 when browser don't accept cookies, browser only adds session Id to URL, on the other side server try to get cookies first and if it is not found then starts new session...How we are keeping session???


case 1:

Server might be not sure about cookies are enabled or not. So, it append the URL too. And on request it checks the cookie, if not found then use the id given in URL.

case 2:

If it gets jsessionid from the URL then it wouldn't go for cookies. I am not sure about this, though.

Or it might go for cookies even already got the id from URL because sessionid in URL can easily be changed by the user, may be by mistake. Cookies might be considered more reliable.

Anyways, nice question.
[ December 05, 2005: Message edited by: Adeel Ansari ]
ankur rathi
Ranch Hand

Joined: Oct 11, 2004
Posts: 3830
Originally posted by Adeel Ansari:



If it gets jsessionid from the URL then it wouldn't go for cookies. I am not sure about this, though.


No, It first checks for cookies than URL for sure.
Adeel Ansari
Ranch Hand

Joined: Aug 15, 2004
Posts: 2874
Originally posted by rathi ji:
No, It first checks for cookies than URL for sure.


What you say about my other ideas?
[ December 05, 2005: Message edited by: Adeel Ansari ]
ankur rathi
Ranch Hand

Joined: Oct 11, 2004
Posts: 3830
I can only guess...
Paul Bourdeaux
Ranch Hand

Joined: May 24, 2004
Posts: 783
It actually depends on what container you are using. The only thing the app requires is that the container has URL rewriting to fall back on when cookies are not accepted. Here is an excerpt from HFS&J that talks about the scenario nicely (I would paraphrase, but they did a pretty good job explaining it, and I want to make sure the point is clear):
Q: Wait a minute... how DOES the Container know that cookies aren't working? At what point does the Container decide to use URL rewriting?

A:
A really dumb Container doesn't care whether cookies work or not - the dumb Container will always attempt to send the cookie AND do URL rewriting each time, even if cookies are working. But here's how a decent Container handles it:

When the Container sees a call to getSession(), and the Container didn't get a session ID with the client's request, the Container now knows that it must attempt to start a new session with the client. At this point, the Container doesn't know if cookies will work, so with this first response back to the client, it tries BOTH cookies and URL rewriting.

...

Now imagine the next request from this client - it will have the session ID appended to the request URL, but if the client accepts cookies, the request will ALSO have a session ID cookie. When the servlet calls request.getSession(), the Container reads the session ID from the request, finds the session, and thinks to itself, "This client accepts cookies, so I can ignore the response.encodeURL() calls. In the response, I'll send a cookie since I know that works, and there's no need for any URL rewriting, so I won't bother...


“Programming today is a race between software engineers striving to build bigger and better idiot-proof programs, and the Universe trying to produce bigger and better idiots. So far, the Universe is winning.” - Rich Cook
ankur rathi
Ranch Hand

Joined: Oct 11, 2004
Posts: 3830

Now imagine the next request from this client - it will have the session ID appended to the request URL, but if the client accepts cookies, the request will ALSO have a session ID cookie. When the servlet calls request.getSession(), the Container reads the session ID from the request, finds the session, and thinks to itself, "This client accepts cookies, so I can ignore the response.encodeURL() calls. In the response, I'll send a cookie since I know that works, and there's no need for any URL rewriting, so I won't bother...


and if the client does not accept cookies then also container will try to read the session Id from cookies (request) and will never get then why should not container creates new session???

And if it creates then it's wrong...

I hope my question is clear..

Please comments
Thanks.




[ December 05, 2005: Message edited by: rathi ji ]
Paul Bourdeaux
Ranch Hand

Joined: May 24, 2004
Posts: 783
The container won't get the session ID from a cookie, but the session ID will be appended to the URL because both cookies and URL rewriting were used on the first request. The container will use the url parameter to retrieve the session, and will also know that cookies did not work. So the container will continue to use URL rewriting.

Hope that helps.
Bosun Bello
Ranch Hand

Joined: Nov 06, 2000
Posts: 1510
Rathi,

If the client does not accept cookies, the container would have known, because, the request will not have the session ID cookie, so the container would have used session ID appended to the request URL.


Bosun (SCJP, SCWCD)
So much trouble in the world -- Bob Marley
ankur rathi
Ranch Hand

Joined: Oct 11, 2004
Posts: 3830
Yes, but it all happens in one line:

HttpSession s = request.getSession();

This line either will return existing session (if cookies are enabled, and this is second request) or will return new session... Where the container is getting chance of looking into URL???

Thanks.
ramprasad madathil
Ranch Hand

Joined: Jan 24, 2005
Posts: 489


Yes, but it all happens in one line:


True, but remember the single api call is for you, the developer. When you call the method, the container does all the work for you under the hood - checking for cookies etc. Its sufficient for the developer to know that he/she will get back a valid session object - either an existing one if any or a new session object.

ram.
ankur rathi
Ranch Hand

Joined: Oct 11, 2004
Posts: 3830
Originally posted by ramprasad madathil:


True, but remember the single api call is for you, the developer. When you call the method, the container does all the work for you under the hood - checking for cookies etc. Its sufficient for the developer to know that he/she will get back a valid session object - either an existing one if any or a new session object.

ram.


You mean to say, in this single call only the container will first look cookie then look URL... but when I told container to go for URL rewriting???

Thanks.
ramprasad madathil
Ranch Hand

Joined: Jan 24, 2005
Posts: 489


but when I told container to go for URL rewriting???


I am sorry, but I cant quite follow your question.

ram.
Vishnu Prakash
Ranch Hand

Joined: Nov 15, 2004
Posts: 1026
Sure you can do that but you shouldn't have request.getSession() method called in your code.


Servlet Spec 2.4/ Jsp Spec 2.0/ JSTL Spec 1.1 - JSTL Tag Documentation
Paul Bourdeaux
Ranch Hand

Joined: May 24, 2004
Posts: 783
You mean to say, in this single call only the container will first look cookie then look URL... but when I told container to go for URL rewriting???

When there is a call to getSession(), the container will ALWAYS look for a session ID cookie first, and if it doesn't find one, look in the URL next. If it still doesn't find a session ID, it will create a new one. URL rewriting just tells the container whether or not to append a session ID to any URLs (links) in the response. It doesn't change the way the call works to get the session.

Sure you can do that but you shouldn't have request.getSession() method called in your code.

I'm not following you here. Why not? That is pretty much the standard way to get the session object...
Vishnu Prakash
Ranch Hand

Joined: Nov 15, 2004
Posts: 1026
I'm not following you here. Why not? That is pretty much the standard way to get the session object...

ofcourse thats the standard way but she was looking to use URL rewriting in the first place.(or I understood in that way)
ankur rathi
Ranch Hand

Joined: Oct 11, 2004
Posts: 3830

URL rewriting just tells the container whether or not to append a session ID to any URLs (links) in the response. It doesn't change the way the call works to get the session.


That point is good.

Thanks everybody. But I am still not clear, when we add URL in response...
ramprasad madathil
Ranch Hand

Joined: Jan 24, 2005
Posts: 489


But I am still not clear, when we add URL in response...


Take a look at my last reply in your other post here.

ram.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: cookies and URL rewriting