The content length filter is clever enough to handle sporadic output
from CGIs, but just because it passes down a brigade with the output
so far doesn't mean it will be sent. By adding a flush bucket to the
end of the brigade, we make sure that core output filter doesn't hold
onto it for a "long time" in case the amount of output is too small to
sent immediately. The content length filter has already figured out
that it will be a "long time" before more output is available.
--- server/protocol.c 19 Sep 2002 12:20:19 -0000 1.1.1.1
+++ server/protocol.c 1 Oct 2002 18:15:44 -0000
@@ -1263,6 +1263,9 @@
*/
if (e != APR_BRIGADE_FIRST(b)) {
apr_bucket_brigade *split = apr_brigade_split(b, e);
+ apr_bucket *flush =
+apr_bucket_flush_create(r->connection->bucket_alloc);
+
+ APR_BRIGADE_INSERT_TAIL(b, flush);
rv = ap_pass_brigade(f->next, b);
if (rv != APR_SUCCESS) {
apr_brigade_destroy(split);
testcase:
printenv with flushing enabled for STDOUT and a sleep after every
output statement
use mod_cgi for handling the cgi request; mod_cgid is busted because
the apr_file_t in the pipe bucket doesn't look like a pipe and the
timeout tricks done by the content length filter are ineffective (the
timeout calls get APR_EINVAL)
--
Jeff Trawick | [EMAIL PROTECTED]
Born in Roswell... married an alien...
