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.cutil_filter.c
Date Sat, 16 Sep 2000 14:48:17 GMT
On Fri, 15 Sep 2000, Greg Ames wrote:
> wrote:
> > 
> > > 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:
> > 
> > 
> > BucketTraceSetup call1 --format text --per-line 80
> > BucketTraceSetup call2 --format hex  --per-line 32
> > 
> This is not as easy for the admin as the syntax Jeff proposed.  (More
> lines to code which must be in sync && more directives) == more rope for
> the admin to hang him/herself with.

There are other problems with the syntax Jeff suggested.  In most cases,
if you have a filter like BucketTrace that has different syntaxes, you
will want to use that filter multiple times with the same syntax.  If the
options are put in the AddOuputFilter line, then the filter cannot be
reproduced without synching with another AddOuputFilter line.

By doing either multiple setupcalls, or by naming the filters with
different names, this problem is solved, and it is much easier to produce
useful error messages.  I am now thinking something along the lines of:

SetupBucketTraceFilter  --output text --cols 80 TEXTBUCKETTRACE

This way, the module is responsible for providing directives that
associate arguments with a given filter, and it is responsible for
producing usable error messages when a filter can't do what the conf file
wants it to do.

> > 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.
> Either way, the onus would be on the module implementor.

No, adding this to the core puts the onus on the core to check with the
filter.  That is wrong.  The core shouldn't be involved here at all.

> > Does the core still
> > try to pass those arguments to the filter?  
> No, it can't - no hook.  If the core sees that there are arguments and
> no hook to parse them,
> it should complain about the AddOutputFilter statement.

Just because there is no hook, doesn't mean it can't try, it just means it
will fail.  Those are two very different conditions.  :-)


View raw message