Mark James wrote:The cause of the problem was my perl code calling flush.pl and flushing STDOUT at a point prior to it printing the response headers.
Hmm, why do you flush?
STDOUT is flushed prior to a fork to exec an external binary (rcs). The child is closing STDOUT and then redirecting it into a pipe to the parent. I didn't write this part of the code, but the comment on the flushing is:
# flush now, lest data in a buffer get flushed on close() in every stinking
# child process.The code for the forking is:
"bulletproof fork" from camel book, 2ed, page 167If necessary I can propose a patch to this perl package to make the flushing conditional on not running under mod_perl.
The way Apache2 is designed is that the moment you send anything down the filter chain, the headers are generated, because they have to be sent before any data goes out. However mod_perl has an internal buffer and it won't flush the data before it gets full or the code tells it to flush using $r->rflush. If $|==0, then the buffer is not used and the data is flushed on every print.
I see. But why is there no problem when using mod_cgi?
Everything seems to work if the ap_rflush call is removed from mpxs_output_flush, but I don't know if this is the proper way to fix it.
No, this is not a proper way to fix it. Otherwise those who want to flush their output won't be able to do so.
Why would a perl handler script want to flush data down the filter chain before it had finished writing all of it?
Mark
