On Sat, Jul 06, 2002 at 12:09:40PM -0700, Ryan Bloom wrote: > Pay attention to what that message says please. It says "The filter > should always be in the stack, and it should always collect > information." It doesn't say "The filter should always be touching the > C-L for the response." We use the data collected by the c-L filter in > other places, so we should always try to compute the C-L in the filter. > However, we should NEVER buffer unless we absolutely have to.
What data is it collecting? r->bytes_sent? We already know what that value will be as it will be identical to the C-L. To make it concrete as to what I have been suggesting in ap_content_length_filter: if (!ctx) { /* first time through */ char *c; c = apr_table_get(r->headers_out, "Content-Length"); if (c) { /* Known content length. */ /* Can we rely on r->clength being valid? Perhaps because of * ap_set_content_length's implementation. If not, we'd have * to convert the c value to an off_t. */ r->bytes_sent += r->clength; ap_remove_output_filter(f); return ap_pass_brigade(f->next, b); } f->ctx = ctx = apr_pcalloc(r->pool, sizeof(struct content_length_ctx)); ...rest of ap_content_length_filter unchanged... Does this make it any clearer? The side effect r->bytes_sent is still maintained and the common case becomes a lot faster and we don't bother to read any of the buckets. -- justin