tomcat-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Larry Reisler" <>
Subject RE: AJP Flush Packet causing text/plain output
Date Tue, 25 Sep 2007 20:45:13 GMT
I understand your hesitation.  I agree that my method was poor in terms of encapsulation, but
was elegant in terms of its size, that it did not change any of the function signatures, and
that it was easy to understand.

The holiday has begun here, and I am off for this week -- I will try to test the patch ASAP.

Thanks so much for your help.


-----Original Message-----
From: Rainer Jung [] 
Sent: Tuesday, September 25, 2007 8:58 PM
To: Tomcat Users List
Subject: Re: AJP Flush Packet causing text/plain output

Hi Lary,

Larry Reisler wrote:
> Thanks for your reply.  There is a holiday here right now, so I'm not
> sure if I will be able to get to file the Bugzilla issue before the
> holiday break.

Maybe this time we are faster than our request ticketing ...

> We tried a few different versions of mod_jk (the early ones had other
> issues), but all the latest ones showed the problem.  We are
> currently using mod_jk 1.2.25.
> In desperation, I was able to create a patch to mod_jk that seems to
> prevent the symptom from occurring.  Here is the diff for the file
> jk_ajp_common.c: 1742,1751d1741 

<         // Removing extra flush buffer if we do not need it.
<         if (headeratclient == JK_FALSE) {
<             int code = (int)jk_b_pget_byte(op->reply,0);
<             unsigned int len = (unsigned int)jk_b_pget_int(op->reply,1);
<             if ((code == JK_AJP13_SEND_BODY_CHUNK) && (len == 0)) {
< jk_log(l, JK_LOG_DEBUG, "Received flushbuffer -- ignoring");
< continue;
<             }
<         }

I'm a little reluctant to use your approach. It should work, but the 
peeking for the message code and length does not belong into the get 
reply function. The best place for the patch would be in the callback 
handling, but there we don't know, if we already received the headers.

So either we pass some additional info to the callback handling (status 
info about the request processing stage), or we prevent the flushing 
later. I decided to move an already existing flag "response_started" 
from the web server private data to  the public service struct and use 
it inside the callback handler.

This patch was committted 
( You can find a 
simple download form of it under

The patch looks lengthy, but in fact did only small changes.

It would be helpful, if you could try it with your reproduction scenario.



To start a new topic, e-mail:
To unsubscribe, e-mail:
For additional commands, e-mail:

To start a new topic, e-mail:
To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message