On 3/16/07, Joe Orton <[EMAIL PROTECTED]> wrote:
http://people.apache.org/~jorton/output-filters.html
I guess I'm confused about the up/down direction convention for output filters? I thought passing the next output filter is "down" and returning to the prior input filter is "up"?
a few examples:
Generally, all metadata buckets should be passed up the filter chain
by an output filter. "down the filter chain"
Filters can create FLUSH buckets and pass these up the filter chain if desired.
"down the filter chain"
An output filter should never pass an empty brigade up the filter chain.
"down the filter chain"
/* Pass brigade upstream. */ rv = ap_pass_brigade(f->next, tmpbb);
/* Pass brigade downstream. */ minor grammatical tweaks:
the number of times a filter is invoked for single response
"for a single response"
The PIPE bucket type is an example of a bucket type has an
indeterminate length; "a bucket type which has an indeterminate length" Possible confusion:
# Output filters which read all the buckets in a brigade must process
a fixed number of >buckets (or amount of data) at a time, to ensure that memory consumption is not >proportional to the size of the content being filtered. This may be unclear, since you're not referring to buckets received on input to the filter but buckets returned by bucket-read (after morphing). Perhaps "must process a fixed amount of data at a time" is less subject to incorrect interpretation?
How does this look?
It looks like a great start to me. More detail about error handling would be invaluable. Something that has been a thorn in the past has been the two types of status and understanding the limited relationship: apr_status_t as returned by a filter HTTP status as returned by a handler What can a filter do to influence HTTP status (set r->status on first invocation for a response?)? What will be logged if a filter returns non-APR_SUCCESS?
