setsides necessary for input filters?

[Joe Schaefer <jo...@sunstarsys.com>]

During the filter-based redesign of apreq, I 
came across the following issue:  I'd like to
avoid making internal copies of the incoming 
data blocks, but I don't know if other filters
(or the content-handler) are allowed to modify
the data itself.  If not, I can just add buckets to 
the apreq filter's internal (context) brigade, which 
(I think) avoids copying the data.

Am I allowed to assume that the incoming request buckets
are always heap-allocated, with immutable data blocks?

-- 
Joe Schaefer

Re: setsides necessary for input filters?

[Cliff Woolley <jw...@virginia.edu>]

On 4 Jan 2003, Joe Schaefer wrote:

> To answer my own question :-), this line in apr_buckets.h describes the
> "read" method for buckets:
>   apr_status_t (*read)(apr_bucket *b, const char **str, apr_size_t *len,
> I interpret the const qualifier here to mean that modifications (to
> the raw data) are disallowed by the bucket API, and that the setaside
> implementation for heap-type buckets is fine as-is.  Is this correct?

That's correct.  In all except one sooper-sekret ;) case, buckets are
write-once.  And even in the sooper-sekret case (which is
apr_brigade_write), it's not modifying the existing contents of the
bucket... only appending to the bucket.

--Cliff

Re: setsides necessary for input filters?

[Joe Schaefer <jo...@sunstarsys.com>]

Joe Schaefer <jo...@sunstarsys.com> writes:

[...]

> If input filters, or the content handler, are really allowed to modify
> the *actual* input data, then the setaside implementation for
> heap-allocated buckets needs to be changed.  It is currently a noop,
> but it probably should make a copy if such modifications are permitted.

To answer my own question :-), this line in apr_buckets.h describes the
"read" method for buckets:

  apr_status_t (*read)(apr_bucket *b, const char **str, apr_size_t *len, 
                                      ^^^^^

I interpret the const qualifier here to mean that modifications (to
the raw data) are disallowed by the bucket API, and that the setaside
implementation for heap-type buckets is fine as-is.  Is this correct?

-- 
Joe Schaefer

Re: setsides necessary for input filters?

[Joe Schaefer <jo...@sunstarsys.com>]

Joe Schaefer <jo...@sunstarsys.com> writes:

> Am I allowed to assume that the incoming request buckets
> are always heap-allocated, with immutable data blocks?

To clarify the issue I'm asking about, here's what the source 
for ap_get_brigade says:

/* 
 * Read data from the next filter in the filter stack.  Data should be 
 * modified in the bucket brigade that is passed in.  The core allocates
 * the bucket brigade, modules that wish to replace large chunks of data or to
 * save data off to the side should probably create their own temporary
 * brigade especially for that use.
 */

If input filters, or the content handler, are really allowed to modify the 
*actual* input data, then the setaside implementation for heap-allocated 
buckets needs to be changed.  It is currently a noop, but it probably
should make a copy if such modifications are permitted.

-- 
Joe Schaefer