On Thu, 26 Sep 2002, Andrew Hill wrote:
> Date: Thu, 26 Sep 2002 17:11:41 +0800
> From: Andrew Hill <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED]
> To: Struts Users Mailing List <[EMAIL PROTECTED]>
> Subject: RE: Disabling jsessionid parameter in Struts forms
>
> You are correct about encodeURL() - this is when the sessionId is appended.
> The sessionId is part of the servlet API session tracking mechanism , and as
> you have noticed is appended to the URL when not using cookies. (When using
> cookies it is instead stored in a cookie).
> If you do not include the sessionId , you will not be able to make much use
> of session scope in your website (as each request will get a new session).
> If you dont need to use session scope to keep track of anything, this
> probably won't be a problem (I think - unless struts itself needs it for
> certain things?).
> As for actually disabling the appending of sessionId I am afraid I have no
> idea how you might achieve it with regards to the struts tags.
>
The "jsessionid" path parameter is indeed added by the call that Struts
automatically makes to response.encodeURL() when setting up URLs for you.
Without this automatic feature, you'd have to call encodeURL() yourself in
order to ensure that your application works when your client does not have
cookies enabled.
So, why does this get generated when my client *does* have cookies? The
reason is that, on the first response for a particular session, the server
has no way to know if you have cookies enabled or not, so the session ID
is sent *both* ways (via URL rewriting and as a cookie). If the session
ID comes back in as a cookie, the server will understand that it no longer
needs to rewrite from the second response on.
There is no configuration parameter to turn this off, and there won't be.
The important principle you should get used to is that the actual contents
of the request URL is pretty meaningless in a web application based on
Model 2 design patterns. You're far better training yourself (and your
users) to ignore the URL completely rather than obsessing over the
detailed contents.
For stubborn users, I've occasionally resorted to running the app in a
frameset with a single frame, just so the location bar URL doesn't change
on every request ...
Craig McClanahan
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
