Mailing-List: contact users-help@tomcat.apache.org; run by ezmlm
Precedence: bulk
Reply-To: "Tomcat Users List" <users@tomcat.apache.org>
Received-SPF: error (athena.apache.org: local policy)
Message-ID: <5202C5EF.80408@christopherschultz.net>
Date: Wed, 07 Aug 2013 18:10:55 -0400
From: Christopher Schultz <chris@christopherschultz.net>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8;
 rv:17.0) Gecko/20130620 Thunderbird/17.0.7
MIME-Version: 1.0
To: Tomcat Users List <users@tomcat.apache.org>
Subject: Re: Responses of two different requests concatinated
References: <65BE686C590EFD4A94F5EEFE17528D6602E31CAC@exchange.kantega.lan>
In-Reply-To: <65BE686C590EFD4A94F5EEFE17528D6602E31CAC@exchange.kantega.lan>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Marvin,

On 8/7/13 6:23 AM, Marvin Lillehaug wrote:
> We recently got an error report from a user of one of the systems
> we have developed, showing that the response from a different
> request had been appended to the original response. The original
> response was the front page of a site, generated with jsp, and the
> appended response was a excel file generated a few seconds
> earlier.

> Our current hypothesis is that some buffer in either httpd(2.2.22)
>  or Tomcat (7.0.35) has been recycled.

Note that the Tomcat documentation uses the word "recycled" with
respect to connections and façades to mean "not re-used". You appear
to be using the term "recycled" to mean "re-used". I just wanted to be
clear because there is a related system property that uses the term
"recycle" (see below).

> Httpd is connected to Tomcat using http proxypass.

First, you should probably upgrade Tomcat to the latest 7.0 version
which is 7.0.42. Is that a possibility?

Second, you should post your whole <Connector> configuration from
Tomcat (minus any sensitive information of course).

If you want a possible quick-fix, you should look at the
RECYCLE_FACADES system property documented here:
http://tomcat.apache.org/tomcat-7.0-doc/config/systemprops.html#Security

If you set that system property to "on", then potential
response-leakages should be significantly reduced at a slight cost in
terms of heap and GC activity (but fairly negligible, as request
façades shouldn't really be surviving any minor collections... they
will just cause minor collections to occur more often).

> I have started trying to reproduce the problem, but thought I
> should try the mailing lists of both httpd and tomcat before
> continuing.

While that's okay, we generally prefer not to cross-post. Here, I have
replied only to the Tomcat users' mailing list as my reply is
Tomcat-specific.

> What I have done thus far is: concatenating html and excel to
> verify that it is possible to open and looks the way the user
> experienced; building a custom version of Tomcat that uses the same
> Processor for each request and configured to use only one thread.
> 
> This seems a bit similar to the issue described in 
> http://tomcat.apache.org/security-7.html#Fixed_in_Apache_Tomcat_7.0.12
>
> 
(CVE-2011-1475)

This is not likely to be your problem, but we'll see when you post
your configuration.

> Some results when googleling suggests that this could happen when
> jsp tags are not coded properly, but I have not found any such code
> in our applications.

Any references? I'm not familiar with any suggestions that JSP tags
are leaky in any way. Are you using any JSPs in these transactions
that appear to have been mixed-up? I'd be surprised to find a JSP that
produces an XLS document.

- -chris
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.14 (Darwin)
Comment: GPGTools - http://gpgtools.org
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBCAAGBQJSAsXsAAoJEBzwKT+lPKRYoBoQALBjqpchPLbwCKpbh2WFcMVY
k++Xc4CopqNwe4uF0PDkU3JHzfWJUIsqZzF1mijOGIwt2EgwQKEZigCyJUv86NTZ
WG2SAc6DupNYwky0i4NnJE2F+VBcdUvTxeQ4LS0ATzr1sNqrmtQxdCbU/VeyAmyb
u5UCmFZiKvVAaepfAEzchTGTUPNqE7Xp57atPfS+EAGwLguE3ARksI9ipEBkOznm
ukRVJBTnrDuQ2/uMsAGW+miWyIeFx64WHGFWXBv/21K3GaSAN2Ut83OWCxCIO7Xr
vZPBtqzFlsfvcjWX3949Zoz0kvNZMCdMkjZ9G7cQhCQT6hWFToqdnXYkQ6U2aqkD
LIryyNiIP5zQFrJOKFKtexyugVNWBcsil4549Wwgi65rmgUeZ8qlEgr1wK4hgvKV
GG+O83kzrxMA4cyyMpgItFIset3+MccCoGHVLQg51afNoDlSfn9pAL8uLZJQW2FT
Prq9r5vD9qu5XyIFUJsHGXGTwWvkn4OPJhcITZsAeBKJxZyYhDNhqjj19fae+o+a
wgmi8XzoDqzCemefOEVXXVidaK0ceuhqUnZF729NavLZV8OUHaPItvS/5jQ4bSBU
BD/UnoDXPL8ZFzPw1WTj1ZotxjDZEAkjnZDUsADfHt2zBtWCxNyizdyIao0B0NAA
j6W/wT1bhYHVZ1eBJR2a
=oSt1
-----END PGP SIGNATURE-----

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tomcat.apache.org
For additional commands, e-mail: users-help@tomcat.apache.org