> There lies the catch and the source of problem in my understanding.
>  In different requests relating to
> the same session, I may get referance to HttpSessionFacade instances which
> are different, but I expect them to be same (although not guarantied by
> specs but I thought it was a tacit agreement between container and servlet
> developer). What I suggest is that tomcat should recycle the
> HttpSessionFacade instance only when the HttpSession instance is
> recycled.This might be more inefficient as it will result in N instances on

You are right, I know what's the problem. It's not hard to fix, but this
week I have no time ( and probably neither next week ), but this bug has
been on my list.

In fact, there is a larger problem here - with very serious security
and performance implications.

To get decent performance you need to recycle ( the cost of allocating
few hundred objects per request is huge - it means the server will
saturate on even small loads). Most servlet containers do recycle - the
problem is common to all of them.

Unfortunately recycling opens a security hole: a (bad) servlet may keep
reference to the HttpServletRequest, HttpServletResponse and HttpSession
objects - and later access the them. That means it'll be able to access
data in a HttpServletRequest that is in use by another servlet, in another
application.

We have most of the elements to fix this hole - and with a decent ( small)
perfomance hit. We need to make sure that a servlet receive only facades
that are local to it's context. That's easy to do by either maintaining a
per/context pool of facades or just doing nothing ( since the facade is
very "light"). 

There is nothing that can be done with the original Request (and  I don't
know any possible fix for this problem in containers that don't use
facades ) - you know the context after you process the request, and then
you've already allocated the request. It may be possible to process the
request line before allocating the request - but that's ugly. Anyway,
that's not a problem in 3.x.


Regarding HttpSessionFacade - you are right, ServerSession should have a
get/setFacade and all getSession() calls should return the same
facade. 1/2 of that is done in 3.3, I just need to do one more change -
it's easy to duplicate this in 3.2 also. Of course, when the session is
invalidated the facade must be either saved in a context-specific pool or
just let it die.

--
Costin


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]

Reply via email to