> From: Filip Hanik - Dev Lists [mailto:devli...@hanik.com] > > 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 have. 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. Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
