Hi Christopher,
Am 16.07.2014 14:45, schrieb Christopher Schultz:
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256
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 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.
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.
But I can at least reproduce the Session Id change mentioned above if
that would be interesting to anyone.
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?
- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iQIcBAEBCAAGBQJTxnPhAAoJEBzwKT+lPKRYWF4P/iP9NXxYvIVLi9rKSUEmjDGI
hcSJ1uMGQDOty0ycNaijR5N9w1QTqhLsoV1cgLaTK3vSvlNpI79b9TEj16EhfY4B
oLAq2QyYLKbwiJm28gp7zcWNup6UgSAdCi/e84g+m0yiD7xZCwgfARAe6k3Idm3q
xjyh6FkNlq9lGxXbRv5TVk5+Nn6/qRQsv6p98DTGna1ypFwupEWB6COzafRKAjuk
icSn1XIAfKSb5NtznPSxqzrxG389I+PX7cFcrxlXHOATY8j6M9kL6JGrKWJS/8bT
KGmP9u6dp7Wuq3/NNYKUhSvDSCILhPqx4ONWl8oTLW0u/crVroKfdJyLFoO89plF
hN3SWCXS7K8MhRHYTZM4qwicjfyUWVlF/+HthO5zvEakfJSDA6KeeCh/Vhtwmi0u
8M9SUM3d05Zv5uZoDAOf27ULDg186kIZD5fnmW2hrV/3ToYseb5yCLY1q71LQfKT
RWNyObvLS/bjouhf6xzozluLD8VZtCNtzptdvx+iYJGzoyUp8Q4/nAtS11FLMn8H
JFzaCFXN7+GEuKj5r/5iE5X4qZPNMIvetW8d2Bp91lZb3y2UPH/9a2CL4GzHyRSp
Xdv94nkDGZlp21sb7xfBgVdbHVxwHz5zITeAbT4sPkq23Wf5O+wtDF+uavmdkorG
7bOwKIvWGaLllyaXbyLB
=8LTx
-----END PGP SIGNATURE-----
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tomcat.apache.org
For additional commands, e-mail: users-h...@tomcat.apache.org
