tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simon Kulessa <>
Subject Re: HttpServletRequest - getHeaders() vs getCookies()
Date Thu, 17 Jul 2014 07:52:08 GMT
Hi Christopher,

Am 16.07.2014 14:45, schrieb Christopher Schultz:
> 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 
<>) 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
> Version: GnuPG v1
> Comment: GPGTools -
> Comment: Using GnuPG with Thunderbird -
> 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
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message