httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Cliff Woolley <cliffwool...@yahoo.com>
Subject Re: [PATCH] Fix CGI flush to network problem
Date Wed, 04 Jul 2001 05:07:26 GMT
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
   cliffwoolley@yahoo.com
   Charlottesville, VA



Mime
View raw message