Yea, I saw your comments. I'll modify the patch to check for APR_SUCCESS with no bytes
read and on a nonblocking call, interpret that as APR_EAGAIN.
Bill
----- Original Message -----
From: "Cliff Woolley" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, July 04, 2001 1:07 AM
Subject: Re: [PATCH] Fix CGI flush to network problem
> On Tue, 3 Jul 2001, Bill Stoddard wrote:
>
> > if (e->length == -1) { /* if length unknown */
> > - rv = apr_bucket_read(e, &ignored, &length, APR_BLOCK_READ);
> > + rv = apr_bucket_read(e, &ignored, &length, APR_NONBLOCK_READ);
> > + if (rv == APR_EAGAIN) {
> > + /* If we can chunk the output, flush the filter chain to
> > + * the network then do a blocking read.
> > + */
> > + if (r->proto_num >= HTTP_VERSION(1,1)) {
> > + apr_bucket_brigade *split;
> > + split = apr_brigade_split(b, e);
> > + rv = ap_fflush(f, b);
> > + if (rv != APR_SUCCESS)
> > + return rv;
> > + b = split;
> > + }
> > + rv = apr_bucket_read(e, &ignored, &length, APR_BLOCK_READ);
> > + }
> > if (rv != APR_SUCCESS) {
> > + ap_log_rerror(APLOG_MARK, APLOG_ERR, rv, r,
"ap_content_length_filter:
> > apr_bucket_read() failed");
> > return rv;
>
> <aside>
>
> This patch brings back up the problem of bucket types (pipe, socket) that
> can return APR_EOF when nonblocking reads are used, when they really ought
> to return APR_SUCCESS. The fact that they don't would break this patch
> (the buckets' fault, not this patch's). Granted, all that will happen in
> this particular case is that you'll get a meaningless error message, but
> that's beside the point.
>
> We agreed on the list months and months ago that they should return
> APR_SUCCESS and just quietly remove themselves from the brigade once they
> were empty. I put a comment that this change needed to be made in the
> buckets code ages ago, but chickened out on actually making the change
> because I was afraid it would break Apache and I wouldn't have known
> exactly where to look to fix it (possibly in the http input filter?
> dunno).
>
> Anyway, We need to go ahead and take care of that so that seemingly
> harmless patches like this don't come back and bite us.
>
> </aside>
>
> --Cliff
>
>
> --------------------------------------------------------------
> Cliff Woolley
> [EMAIL PROTECTED]
> Charlottesville, VA
>
>
