> 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...
+1. This replicates the desirable behaviour of 1.3
Bill
