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???
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.
Originally posted by rathi ji:
No, It first checks for cookies than URL for sure.
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
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
Bosun (SCJP, SCWCD).
So much trouble in the world -- Bob Marley
Yes, but it all happens in one line:
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.
but when I told container to go for URL rewriting???
“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
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.
We find this kind of rampant individuality very disturbing. But not this tiny ad:
a bit of art, as a gift, the permaculture playing cards
https://gardener-gift.com
|