You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Jeff Trawick <tr...@bellsouth.net> on 2000/09/01 02:50:19 UTC

Re: Thoughts on filter-chain composition

Rodent of Unusual Size <Ke...@Golux.Com> writes:

> 1. Content filter order is controlled by config directives.  For
>    the moment, let's only think about *output* content filter.
>    Posit the addition of an 'AddOutputFilter' ITERATE2 directive,
>    that takes an extension or IMT as its first argument, and an
>    ordered list of filter names for the remainder.  For instance,
> 
>    <Location /signed-distros>
>        AddOutputFilter */* gzip-content pgp-sign-content
>    </Location>
>    <Location /signed-files>
>        AddOutputFilter */* pgp-sign-content gzip-content
>    </Location>
> 
>    (AddOutputFilter sets a precedent for input filter chains
>    when we're ready to deal with them.  I suggest we defer them
>    for now. :-)
> 
>    AddOutputFilter would be the normal way to add filters.
> 
>    Having AddOutputFilter take either a file extension or an
>    IMT is particularly useful in the oft-requested case of
>    parsing CGI output; if we use "AddOutputFilter text/html ssi-parse"
>    and a script emits something other than text/html, we don't
>    waste cycles (and possibly munging binary output) by trying
>    to parse it.

I like this a lot and would really like to see some progress on this!
Such a directive is required IMHO.  I don't see modules always being
able to determine where their filter goes and I would hate to see various
filter-laden modules implementing their own directives to help them
figure out where to insert their filters.

Should I presume that this is not intended to deal with connection
filters?

A few issues come to mind...

1) reconciling a module's ability to ap_add_filter() its filter
   (somewhere :) ) with the administrator's ability to explicitly
   specify an order for the various filters

   Do we ignore calls to ap_add_filter() if AddOutputFilter was
   specified, or do we let the module know that the filter was added
   via AddOutputFilter such that the module doesn't call
   ap_add_filter()?

2) providing a way to set up the context of a filter which was
   inserted due to AddOutputFilter

   (this could let the module know not to ap_add_filter())

3) providing a way to use different instances of the same filter in
   the same filter chain but with each instance using a different
   configuration, or char string argument, or something so that it can
   act differently

   This is analogous to using grep in multiple stages of a pipeline at
   the Unix command-line.  Each instance of grep needs its own
   arguments.

-- 
Jeff Trawick | trawick@ibm.net | PGP public key at web site:
     http://www.geocities.com/SiliconValley/Park/9289/
          Born in Roswell... married an alien...

Re: Thoughts on filter-chain composition

Posted by Rodent of Unusual Size <Ke...@Golux.Com>.
Jeff Trawick wrote:
> 
> Should I presume that this is not intended to deal with connection
> filters?

Correct.

> 1) reconciling a module's ability to ap_add_filter() its filter
>    (somewhere :) ) with the administrator's ability to explicitly
>    specify an order for the various filters
> 
>    Do we ignore calls to ap_add_filter() if AddOutputFilter was
>    specified, or do we let the module know that the filter was added
>    via AddOutputFilter such that the module doesn't call
>    ap_add_filter()?

Ignore, I think, with a message in the errorlog.

> 2) providing a way to set up the context of a filter which was
>    inserted due to AddOutputFilter
> 
>    (this could let the module know not to ap_add_filter())

Possibly as simple as ap_filter_in_stack(r->filters, "name").

> 3) providing a way to use different instances of the same filter in
>    the same filter chain but with each instance using a different
>    configuration, or char string argument, or something so that it can
>    act differently

Hmm.

AddOutputFilter text/plain fname/"arg1 arg2" fname/"arg3 arg 4 arg5"

maybe?  Or "fname(arg arg2)" possibly?
-- 
#ken    P-)}

Ken Coar                    <http://Golux.Com/coar/>
Apache Software Foundation  <http://www.apache.org/>
"Apache Server for Dummies" <http://Apache-Server.Com/>
"Apache Server Unleashed"   <http://ApacheUnleashed.Com/>