3 messages in org.apache.struts.userRe: URL Re-writing?| From | Sent On | Attachments |
|---|---|---|
| David White | Jul 4, 2001 11:10 am | |
| Kief Morris | Jul 4, 2001 11:13 am | |
| Craig R. McClanahan | Jul 15, 2001 10:46 pm |
| Subject: | Re: URL Re-writing? | |
|---|---|---|
| From: | Craig R. McClanahan (crai...@apache.org) | |
| Date: | Jul 15, 2001 10:46:51 pm | |
| List: | org.apache.struts.user | |
On Wed, 4 Jul 2001, David White wrote:
I am new to struts/jsp/etc.
I understand that the struts framework can automatically handle session management via URL re-writing if the user's browser does not permit cookies to be used.
The funny thing is that sometimes, my browser shows a jsessionid value in the address box and other times it does not. I would expect that I would ONLY see this value if my browser had cookie support disabled and that all other times, I would see nothing as cookie support is enabled and URL re-writing is not required.
What I actually see is that sometimes I do not see the value displayed and other times I will see it. Even when cookies are enabled, I may still see this value.
I am puzzled. Any help is appreciated.
The first time that you make a request that is part of a session, the servlet container has no clue about whether or not the client supports cookies. Therefore, it sends the session ID *both* ways (as a cookie and as an encoded URL). Then, when the next request comes in, the container can look at whether the cookie is present and say either:
- "Aha, this client supports cookies. Therefore I don't need to encode URLs any more -- we'll just use cookies."
- "Aha', this client doesn't support cookies. Therefore, I will continue to use URL rewriting."
The key issue is that the container has no idea which scenario will occur until the *second* request. Therefore, the only rational strategy is to send the session identifier both ways the first time, and see which one comes back.
Thanks,
David Seattle
Craig McClanahan