httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From r..@covalent.net
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
directive.

I am thinking something like:

AddOutputFilter INCLUDES BUCKETTRACE XLATEOUT BUCKETTRACE

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
user.

Ryan

_______________________________________________________________________________
Ryan Bloom                        	rbb@apache.org
406 29th St.
San Francisco, CA 94131
-------------------------------------------------------------------------------


Mime
View raw message