-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Gunay,
On 4/21/12 2:58 AM, gunay arslan wrote: > Seems like I could not explain what exactly I was trying to show. > A reference implementation of the PageContextImpl is attached, and > I tested this with one of our in-house web application. The point > is This is a discussion best had on the users' list. I'm cross-posting here to encourage a transition. > 1) Spec says that a session variable needs to be present: but this > creates a problem for the web applications, as a simple attack to > a web application can force creation of dummy sessions, filling the > memory. Most of the applications are using some sort of persistent > session management, which is another problem, as this increases the > processing time , for these dummy sessions. There are many ways to create a session without even hitting a JSP. Closing this "hole" doesn't safeguard the server from such an attack. You'll need to use some other mechanism to prevent a malicious client from creating sessions without bound. > 2) Most of the applications do not use the session inside the jsp That's not only a fairly big assertion, it also suggests that it's okay to violate the spec. Which is not a good idea. > , so why to create a new session , before it is needed ?? Maybe we > can name the definition LAZY_SESSION_CREATION ?? Konstantin already explained that there needs to be a local variable available called "session" for scriptlets. If the spec required that all session access be routed through some method (such as HttpServletRequest.getSession), then your suggestion might be possible. Instead, the spec requires that there be a valid, non-null local variable available to scriplets. This is not possible with any kind of lazy-loading scenario. > 3) Most of the applications , do not create a session in the jsp, > the session is created at the servlet level, and just checked for > attribute presence at the jsp level. Another fairly big assertion. Maybe this is how things are in your own webapp, but yours is different from everyone else's. > My point is to reduce the number of "useless created sessions", > the same problem was described at > http://www.tomcatexpert.com/blog/2011/05/18/crawler-session-manager-valve > , showing a simple solution, but this solution does not solve the > real problem. The real problem is that the webapp is (perhaps inadvertently) requesting that the container create sessions when they are not necessary. The solution is to fix the webapp. Tomcat can only be leveraged to stop the bleeding while you go repair the root of the problem. It might be worthwhile proposing a setting for Jasper where the default "session" setting could be set to "false" (in obvious violation of the servlet specification) so that JSPs must specifically set session="true" in their headers, but such a patch might be very far-reaching. Personally, I would find it easier to write a simple search-and-replace (search-and-add?) script to find JSPs that don't need sessions and set session="false" in their <%@page> directives. - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.17 (Darwin) Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAk+VvUkACgkQ9CaO5/Lv0PCmPwCdH8qhXYPjpGvJICnMRIa7Dq2/ qrYAnjEy4X0oU//7UB+0y44aRGtVupfN =rkI8 -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
