httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Justin Erenkrantz <jerenkra...@apache.org>
Subject Removing C-L filter when C-L is known was Re: conserving file descriptors vs. ap_save_brigade()
Date Sat, 06 Jul 2002 20:08:29 GMT
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

Mime
View raw message