httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject Re: cvs commit: apache-2.0/src/main http_core.c http_protocol.c util_filter.c
Date Fri, 15 Sep 2000 16:36:57 GMT

> Even with the context param of ap_add_filter(), more is needed for
> certain types of filters, particularly those which may be used more
> than once in the same filter chain with different parameters.  
> Is anybody opposed to extending what Ryan committed with something
> like the following?
> AddOutputFilter INCLUDES                                 \
>                 BUCKETTRACE(--format text --per-line 80) \
>                 XLATEOUT                                 \
>                 BUCKETTRACE(--format hex --per-line 32)

Yes, I am.  This puts way too much in one directive.  This can be solved
by having the module that implements BUCKETTRACE also have it's own

I am thinking something like:


BucketTraceSetup call1 --format text --per-line 80
BucketTraceSetup call2 --format hex  --per-line 32

With some very simple module magic, you can easily associate the Setup
with the call to the BucketTrace filter.  This puts the onus on the module
implementor to allow setup for their module.

> The string inside parens would be stored as-is (raw) in f->params.  If
> no string was specified, f->params would be NULL.

AddOuputFilter should be very simple, not trying to do too much.  What
happens if a filter doesn't implement any arguments?  Does the core still
try to pass those arguments to the filter?  The core can't determine if
the filter takes arguments, so we can't return any kind of error to the


Ryan Bloom               
406 29th St.
San Francisco, CA 94131

View raw message