Hi, I don't want to chop off any parts of your email because it nicely establishes the context for the question, so I'll leave it all below.
It's not obvious to me that option #1 is not acceptable. It raises the bar on the includer, perhaps, but it's not obviously unacceptable. Am I missing some relevant portion of the Servlet Spec here? Yoav --- Jan Luehe <[EMAIL PROTECTED]> wrote: > I have a question regarding session invalidation in the target context > of a RequestDispatcher.include(). > > Some background info: The current impl of package > org.apache.catalina.core.ApplicationHttpRequest.getSession() creates a > session in the target context of a RD.include() as follows: > > - Checks if the origin context has any active session. > - If the origin context has no active session, creates a session in > the origin context. > - Creates a session in the target context, and assigns to it the > id of the session in the origin context. > > The requirement of having the sessions in the origin and target > contexts share the same session id is due to the fact that any context > that is the target of a RD.include() must not change any of the > response headers (and therefore must not add any Set-Cookie response > header) as per the Servlet Spec (SRV.8.3). > > This approach has worked well - as long as the target context > does not decide to invalidate its session and acquire a new > session. In that scenario, the current impl returns the invalidated > session as the new session, causing IllegalStateException to be thrown > when the session is accessed. This is because we currently don't > check if "localSession", which is assigned as follows: > > localSession = context.getManager().findSession(other.getId()); > > is valid before returning it. > > We can easily fix this so that the invalidated session is no longer > returned, but what should the newly generated session look like? > I can see the following options: > > If the target context invalidates its session and then requests a new > session .... > > - OPTION 1: > > ... we also invalidate the session in the origin context, create > a new session in the origin context, create a new session in the > target context, and assign the id of the new session in the origin > context to the new session in the target context. Obviously, this > option is unacceptable as it destroys any session data in the origin > context. > > - OPTION 2: > > ... in the target context, we purge the invalidated session immediately > before creating a new session and assigning to it the session id > of the invalidated session (which is still equal to the id of the > session in the origin context). This approach would violate the > uniqueness requirement of session ids per context, but I don't see > this as a problem, because this is happening within the same request. > > > Any other opinions? > > > Thanks, > > > Jan > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
