[..]
| - how exactly does one "override" the Tomcat-generated JSESSIONID
| cookie? Just by overwriting it after Tomcat created it anyway ?
Yes.
| (And, as a secondary question, what does one exactly put in it then, so
| that it still matches the "session key" ? Or can you just put something
| arbitrary in it, and Tomcat will use whatever is there to identify the
| session data store ?)
The cookie must be called JSESSIONID, and the value must be the id of
the session. So, you can just do something like this:
response.addCookie(new Cookie("JSESSIONID",
~ request.getSession().getId());
Technically, this creates an additional cookie with the same name, and
I'm not sure how Tomcat (or the browser) handles this. You could use
LiveHTTPHeaders or an equivalent to see what is sent by the server, and
then from the browser.
From http://www.faqs.org/rfcs/rfc2965.html :
3.3.3 Cookie Management If a user agent receives a Set-Cookie2
response header whose NAME is the same as that of a cookie it has
previously stored, the new cookie supersedes the old when: the old
... (summary of conditions : domain and other significant attributes
equal)
So I guess we can assume that if the browser receives 2 "Set-Cookie" or
"Set-Cookie2" headers in a row, and the cookies have the same name, the
second one SHOULD override the first.
The RFC is not very clear if this applies only to cookies received in
separate response, or also within the same response, but I guess one can
reasonably assume..
To nitpick, one uncertainty however is whether response.addCookie() and
co. respect the order in which you called them, in terms of in which
sequence the HTTP headers are effectively written out to the browser in
the HTTP response header. Are the servlet specs clear for that ?
---------------------------------------------------------------------
To start a new topic, e-mail: users@tomcat.apache.org
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
