httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@covalent.net
Subject Re: cvs commit: apache-2.0/src/main http_protocol.c
Date Thu, 12 Oct 2000 04:27:52 GMT

> Don't you want to hold onto remaining buckets between invocations?
> Here is the set of changes I was soon to commit to get POSTs working
> again :) 

No, there is no reason to keep c->remaining intact between
invocations.  The whole point of c->remaining is to say "grab no more than
this much data from the bucket brigade and return it to me."  Once we have
returned that much data, the remaining field is invalid.

> Index: main/http_protocol.c
> ===================================================================
> RCS file: /home/cvspublic/apache-2.0/src/main/http_protocol.c,v
> retrieving revision 1.160
> diff -u -r1.160 http_protocol.c
> --- main/http_protocol.c        2000/10/12 02:54:38     1.160
> +++ main/http_protocol.c        2000/10/12 04:18:32
> @@ -2398,10 +2398,23 @@
>      apr_status_t rv;
>      apr_int32_t timeout;
>  
> +    if (!r->connection->input_data) {
> +        /* XXX used only by ap_get_client_block(), lifetime is request;
> +         * move from c to r and fix the pool
> +         */
> +        r->connection->input_data = ap_brigade_create(r->connection->pool);
> +    }

I stopped using r->connection->input_data, because it isn't this filter's
to use.  In fact, this can actually go away now.  The whole point of this
brigade, was to give the core filter a place to store information.  It is
incorrect for any filter to have access to a brigade in the conn_rec.

>      if (!r->read_chunked) {     /* Content-length read */
>          ap_bucket *b;
>          const char *tempbuf;
> +
> +        if (!r->remaining) {
> +            /* We can't call http_filter() again to find out because when
> +             * c->remaining is zero it returns lines of protocol data.
> +             */
> +            return 0;
> +        }

This is a good change that needs to be made.

Ryan
_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------


Mime
View raw message