HI Christopher,
As a web application developer, I needed to stop creation vast amount of
"dummy" sessions, that is why I proposed this. I understand that specs are
important and there are vast amount of
software that requires these spec to be applied to run.
What I am proposing is , we can add a non-distructive variable with default
value working as the spec dictates. If anyone want to optimize session creation
they can change the value. There are many such variables across the tomcat,
that you can tweak.
My business is running on top of Tomcat, it is important for me to have a
better Tomcat, more reliable, more high-performance.
BTW. send-replace method does not solve the problem
a very common pattern in a jsp/jstl is
<c:if test="${sesssionScope.xxxx } >
---
</c:if>
where test test is performed on existence of a variable in session.
at this point I want this jsp to run without a problem but,
the scop should be run without a problem on existing session
if session does not exists then a new session should not be created
if I say session="true" on top of jsp, then every time a new session is
created. If I say session="false" then eve if there is a session available , it
is not transferred to the jsp , maybe a lighter solution will be putting a
session to page even when session="false" , in case there is an existing
session ?
best regards,
Gunay Arslan
On Apr 23, 2012, at 11:36 PM, Christopher Schultz wrote:
> -----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: dev-unsubscr...@tomcat.apache.org
> For additional commands, e-mail: dev-h...@tomcat.apache.org
>
