tomcat-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Remy Maucherat <>
Subject Re: svn commit: r582291 - /tomcat/tc6.0.x/trunk/STATUS
Date Fri, 05 Oct 2007 15:49:13 GMT
Rainer Jung wrote:
> wrote:
>> +* Fix explicit flush before response commit in the org.apache.jk AJP 
>> connector.
>> +
>> +  +  +1: remm
> I admit, that I don't have a better solution, but nevertheless a 
> question: In case the flush comes to early, i.e. before the headers are 
> set up correctly, it wcould be safer to drop the flush.
> The reason for a flush usually is, to make sure, that prepared 
> information reaches the client soon, and is not kept back by any buffering.
> Detecting an unconditional flush is not easy, so I'm OK to commit and 
> flush, whenever it makes sense. But if we are to early in the request 
> handling, we will send out headers, that might not fit to the response 
> generated later.
> So my question is: is there a reliable way to detect, if it would be 
> safer to just drop a flush request?

I think flush should still send a flush packet. One scenario would be 
(in the servlet): write 10 bytes and flush (in this case, the response 
has not been committed yet). The server should write the response 
header, then make sure the 10 bytes are sent because it has to send them 
right away. AFAIK, the front end server will not do that without the 
explicit flush.


To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message