-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Simon,
On 7/17/14, 3:52 AM, Simon Kulessa wrote: > Hi Christopher, > > Am 16.07.2014 14:45, schrieb Christopher Schultz: Simon, > > On 7/16/14, 4:02 AM, Simon Kulessa wrote: >>>> Am 15.07.2014 16:12, schrieb Christopher Schultz: Simon, >>>> >>>> On 7/9/14, 4:51 AM, Simon Kulessa wrote: >>>>>>> I had a look at the documentation and the tomcat source >>>>>>> to get a better understanding of what the >>>>>>> '|org.apache.catalina.connector.RECYCLE_FACADE' >>>>>>> parameter actually does.| >>>>>>> >>>>>>> I have seen that Tomcat objects like Cookies, Request >>>>>>> etc. are designed to be reusable. >>>> Requests, yes. I haven't looked to see if Cookies would be >>>> re-usable but it seems plausible. >>>> >>>>>>> What I currently do not understand is: In which >>>>>>> scenario and what context are they going to be reused? >>>>>>> I see there are Endpoints classes (like NIOEndpoint) >>>>>>> which are used to process the different requests. This >>>>>>> seems to be the most likely entry point into the >>>>>>> scenario. >>>>>>> >>>>>>> Maybe somebody can provide some general outline of how >>>>>>> requests and the reusing of the object actually works >>>>>>> together? Is there some kind of relation to the IP of >>>>>>> an incoming request? >>>> The client's IP is irrelevant: Tomcat uses a pool of objects >>>> and re-fills each object with data from an incoming request. >>>> These objects, as far as the web application should be >>>> concerned, should have a valid lifetime equal to the request >>>> itself. The servlet spec requires these semantics, so this >>>> isn't some weird Tomcat thing. Tomcat has chosen to pool >>>> these objects for a small performance gain when it comes to >>>> memory management and garbage collection. >>>> >>>> If your application retains references to these objects after >>>> they become invalid, they may contain invalid data or valid >>>> data from another request after they should have become >>>> invalid form the perspective of the original request. >>>> >>>> If you need data from a request, cookie, etc. then you should >>>> copy it somewhere safe before the request ends. >>>>> We do not cache any request specific information. The IP >>>>> relation itself is irrelevant - it seems that the reused >>>>> object's contains more 'old' informations than I >>>>> previously assumed. The header itself and the >>>>> requestedSessionId seems to be changed, the sourceIP and >>>>> the cookie stay the same. > > I checked, and Tomcat does not appear to cache Cookie objects in > any way. If the request object is cached and there is a terrible > bug, it might be possible to re-read an incorrect session cookie > from an old set of request headers. > >> At least the cookies have a recycle() method, which is called if >> a request is recycled. I don't see a recycle() method in the Cookie class. Where do you see that? > I honestly think it's unlikely that there is such a bug in Tomcat. > >> There was a bug in Tomcat (CVE-2011-3375 >> <http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2011-3375>) >> related to an incorrect recycling of the objects which seemed to >> be there for quite some time, but was fixed for 7.0.22. Yes, a bug was found in the past. Does that mean there could be a bug here? Sure, but I think it's unlikely that you have found one. >> I doubt as well that this is actually a bug in Tomcat, but I >> wouldn't rule this out completely. > > At this point, I think you're probably going to have to create a > proof-of-concept web application that reproduces this problem. Do > you think you could boil-down the problem to a single servlet that > demonstrates what you are observing? > >> I tried to do that (it's a little bit more complex than just a >> single servlet), but so far I did not succeed. If we can't reproduce it, we can't investigate it. Please keep trying. There are ways to securely deliver a test case if you can't divorce the problem from your confidential code. >> But I can at least reproduce the Session Id change mentioned >> above if that would be interesting to anyone. I don't even understand the "session id change" that you described so it would be helpful to have a test case for that. >> Recently I start to wonder whether the Implementation of >> javax.servlet.AsyncContext might actually cache the original >> request. The interface at least suggest that it could have these >> information. I did not look at the implementation yet. > >> At least the AsyncContext is created based on the Request. But >> the whole point of this thing is to be shared between requests, >> or am I wrong there? Are you caching the AsyncContext yourself, or are you using an AsyncListener to capture events and using the AsyncContext that comes from the event? Can you even give us some pseudocode that shows what you are trying to do? So far, all you've really said is "Tomcat is messing-up my sessions". It took you 3 posts to mention that you were using Servlet 3.0 async, which might be the most important piece of information after the version you are using. Since your version is old, you really should upgrade regardless of the outcome of this conversation. In fact, there have been so many changes and tweaks to the async-related code over the years (/literally/ years since your release came out) that this problem may not even exist anymore. Can you reproduce the problem in a test environment with 7.0.29? - -chris -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: GPGTools - http://gpgtools.org Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBCAAGBQJTx9s6AAoJEBzwKT+lPKRYivIQAKGxXTjPPswuwAlvB8i2AYuL MJV6epY4HyAU1X7ovHcBcmUZ86Vt/zx0ehCgmKSToT/VcWMy8LROgzyDZa9kM3He /LNMCQpUACt6RRw08lntuOgQDxyNchedWdXFWbI2glpWrVGHNfzszDZ66pHJAkxG U8umNY7v6DWeNhjOehwF4x5JwSr/mozhtbK82l/ycl/QhUFeHm1zTBufVnBEtais L7N8G0L4heOt2F1Vh8IEyaEt8IvK+5kpQnLdRpkj4qplVfjbtpirJJpF5vY96VHa haTKKwHvM9axFY0CRhlV1+MFUnAfMUivRqqqGWPHXesi5Ao/pEDMcFJHy3IJZhG+ rRaHBKH8JAkUNqnQxNaV1W4iZGfRtpEjdTVheat4B/Skrn2aIHmV5MQLVgtXCw8i jg2Lo9IgcXdYphBluOS9xd47r603b34wNNEyzAOO8sWL51kjfR48tAwcPD9WM11W Sh8+OtWZd4HOjm/zOAGUHZodH/JuAr/F4yn9CEDjoxsMU5I4R+0pY8j5EHY0YXhI L08M3OqyLItuA6Y0kYI7ZPnCedg+K+xN57h0plEEw5orvkyNEKjKPpBwgQkDb/AV qMTvU2AcXOj0zYOZCfppHXvtpjsjAuYDoXtY+NrQTTo1w91V4n1QhXr8aq+zlUcp /oX1KuwaNyo3rVaPS+B0 =31cb -----END PGP SIGNATURE----- --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org For additional commands, e-mail: users-h...@tomcat.apache.org
