tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Mark Thomas" <>
Subject RE: svn commit: r733748 - in /tomcat/trunk: java/org/apache/catalina/ java/org/apache/catalina/connector/ java/org/apache/catalina/core/ java/org/apache/catalina/ha/session/ java/org/apache/catalina/session/ java/org/apache/coyote/ java/org/apache/coyote/
Date Mon, 12 Jan 2009 16:50:26 GMT
> From: Filip Hanik - Dev Lists []
> this implementation may ask for more than is warranted. I would -1
> based
> on for example
> > "javax.servlet.request.ssl_session_mgr";
> shouldn't extensions be named differently, and not within the
> javax.servlet namespace?

We already have custom extensions for SSL attributes in this namespace.

> SSLSessionManager.invalidateSession
>  > not sure why the SSL sessions should invalidated when a HttpSession
> is invalidated. I should be able to continue my SSL session even after
> I
> invalidate my HttpSession

There have been a few requests on the users list for the ability to invalidate the SSL session.
I wanted to see what the code would look like. I'm not against removing the SSL session invalidation
part of this patch. The downside would be the inability to invalidate the SSL Session, the
plus would be simpler code and the removal of some of the restrictions on when you could use
SSL session tracking.

Some clarification from the EG on what session.invalidate() means when using SSL tracking
would be helpful. The doc on this area is just what is in the Javadoc and that doesn't really
give any insight into the thinking that went on behind this particualr change.

> also, there are so many changes for this, when in fact the request you
> already have the SSL session ID in the request attribute
> SSL session id -> javax.servlet.request.ssl_session_id of type
> java.lang.String
> why tracking sessions using SSL is part of the servlet spec, there are
> probably many different ways of implementing it, and I think it could
> be
> simpler than this, so maybe its a good idea to discuss such changes on
> the dev list first.

The simple solution, as you suggest, is just to use the SSL Session ID. I had that working
quite quickly with a much smaller patch.

As I type and the more I think about this, it really does come down to what session.invalidate()
means when using SSL Session tracking. If you were using cookies, then the session ID would
be reused. That suggests it isn't necessary to invalidate the SSL session. However, there
is a demand from the user community for this ability and I think it is a useful feature to

On reflection, I might have a way to invalidate the SSL session without all the extra code.
I'll do some testing and post the results.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message